menu

Figma

Figma is the first collaborative UI design tool built in the browser. Join our growing community and kick off a conversation!

Channels
# All channels
view-forward
# General
view-forward
# Start Here
view-forward
# Announcements
view-forward
# Design Systems
view-forward
# Plugins & API
view-forward
# Made with Figma
view-forward
# Prototyping
view-forward
Team
The Figma community has a new home. This thread is preserved for historical purposes. The content of this conversation may be innaccurrate or out of date. Go to new community home →

Version Control

February 6, 2019 at 9:01pm
Hi!
My journey have been Sketch -> Figma -> Sketch. Whereas Figma was a great discovery and I love how streamlined is the component management, there are 3 major reasons for the move back to Sketch:
  • Open-source plugin environment (we build internal plugins in Product Design team)
  • Team being used to Sketch
  • Version Control (Abstract)
My question is: how do you guys control version in Design teams using Figma? Is there any Abstract equivalent for Figma?
Thanks!
Show previous messages

February 7, 2019 at 8:41pm
the solution we're using to handle version control at my work is —
Every project has two files, the 'Designer File' and the 'Developer File'. Designers work inside of the designer file, and the developers refer to the developer file.
When the designers meet with a client, users or internally for a feedback session, we use the in-built version functionality to mark each iteration as a new version.
When the client signs off on an iteration or change, we copy over the UI from the designer file into the developer file under a new 'Page'. The page is dated, given a version and a small title or description (for instance 'Feb 5th – v1.2 – Minor consistency tweaks). Then we produce a change log inside of Confluence outlining both a high-level summary of the changes, then a nitty-gritty screen-by-screen list of changes between the latest version and the previous version.
This way the developers only have to refer to one link, and they know the page at the top of the 'Pages' panel will be the latest (with a date to confirm). It also means the designers can have a working file that isn't being referenced to by developers.
like-fill
5
  • reply
  • like

February 8, 2019 at 9:06am
the solution we're using to handle version control at my work is —
Every project has two files, the 'Designer File' and the 'Developer File'. Designers work inside of the designer file, and the developers refer to the developer file.
When the designers meet with a client, users or internally for a feedback session, we use the in-built version functionality to mark each iteration as a new version.
When the client signs off on an iteration or change, we copy over the UI from the designer file into the developer file under a new 'Page'. The page is dated, given a version and a small title or description (for instance 'Feb 5th – v1.2 – Minor consistency tweaks). Then we produce a change log inside of Confluence outlining both a high-level summary of the changes, then a nitty-gritty screen-by-screen list of changes between the latest version and the previous version.
This way the developers only have to refer to one link, and they know the page at the top of the 'Pages' panel will be the latest (with a date to confirm). It also means the designers can have a working file that isn't being referenced to by developers.
That's a great overview you will lose the comments on the copy but I don't think they are relevant to develop if they have the release notes.
  • reply
  • like

February 8, 2019 at 5:48pm
Each file corresponds to a JIRA issue for us. And the document is named accordingly. (ie. LPA-123) And then title with the feature, view, etc. and the date the file was last touched. Within the file we have Live, Verification, Iteration, and Prototype pages. Both Iteration and Prototype pages can have multiple pages with different names depending on the complexity of the design challenges.
like-fill
2
  • reply
  • like
Live is what the developers work from, and they have access to the other pages throughout to help provide feedback..and general interaction. Verification is where UI elements go that Product / Business need to give the thumbs up on before moving forward. Iteration is of course iterations on designs with prototypes being interactive click-throughs.
  • reply
  • like
Anytime we make a major set of changes we (ctrl-alt + s) and create a new version with an accompanying name and description. And we also clear out iterations as we are refining, and rely on version history if we happen to need something new, or decide to revert to a specific path from an earlier iterations.
  • reply
  • like
We create "branches" by simply adding branch after the name in the original title. We limit this as often as possible as we like to live within a single file if possible. This allows comments, and the design history to remain together.
  • reply
  • like
We also have a Design System Library that everything feeds from, and a "Views" Project that contains all the completed screens separate by app, and specific target. That's our workflow in a nutshell.
  • reply
  • like

February 11, 2019 at 7:46am
sounds interesting but how do you move things from Verification/Iteration to Live and how do you communicate it to developers? Is there any automatism around it or is it manual work?
Also, how do you manage conflicts in case you find some?
  • reply
  • like
Products get moved from Iterations to Verification when design believes it's ready for Product and Business to review. Then once they have approved the design it gets moved into Live. Figma has commenting. We either ping members of engineering in Figma, OR we discuss and review with them as needed.
like-fill
4
  • reply
  • like
Conflicts? We have yet to have anything I'd consider a conflict. You don't merge files. You just edit one together. If we have a separate file we simply copy it in.
like-fill
1
  • reply
  • like
I had similar questions here https://spectrum.chat/figma/tips-and-tricks/versions-vs-branches~da9bee6b-a3d7-4142-a464-59c5adffff91 and reached out to the team before committing. They told me at the time it wasn't on their roadmap. But that was a few months ago.
  • reply
  • like

February 11, 2019 at 11:12pm
I've noticed that teams are managing versioning in Figma in a few different ways. We do have built in version history and the ability to create checkpoints in Figma, but we agree this system could be a bit more robust, and it's something we're actively thinking about. :)
The versioning could def be a bit more robust, and given the nature of the tool it seems like the audit log should be a basic feature not just for organizations. We end up relying on Sketch w Abstract to offer a birds eye view.
  • reply
  • like

February 19, 2019 at 2:06pm
this is definitely the hardest part of the collaboration. writing down changes, that can be so different (from content, imagens, copy, flows, visual details...) and communicate them clearly to be implemented
  • reply
  • like
  • reply
  • like
Live is what the developers work from, and they have access to the other pages throughout to help provide feedback..and general interaction. Verification is where UI elements go that Product / Business need to give the thumbs up on before moving forward. Iteration is of course iterations on designs with prototypes being interactive click-throughs.
On your Verification Page, do you display the UI screens mixed with flows? see pic please
  • reply
  • like
No. We have a prototype page. That is it's own thing. The flow itself is established well before the Hi-Fi static views are set in stone. By the time those are done, and verified everyone knows the user flow.
  • reply
  • like
No. We have a prototype page. That is it's own thing. The flow itself is established well before the Hi-Fi static views are set in stone. By the time those are done, and verified everyone knows the user flow.
hmmm, so you just share prototypes with the team. I'm used to always mix hi-fi static screens and prototypes and flows, never separate them. And I always share links of specific Page files or specific Prototype screens, it depends.
Edited
  • reply
  • like
Flows should always be established, and defined before Hi-Fi. In my experience getting that defined allows me to focus on the details in the static views.
like-fill
3
  • reply
  • like
Micro-Interactions (when needed are done later, and reference the prototype clickthrough when needed)
  • reply
  • like
I find it hard to show different kind of flows when I design something that has a lot of conditionality. E.g. a big survey where the user chooses different options and those different options will lead to different paths.
Designing the hi-fi separated from the context of the conditional flows get's hard. (the low-fi are also designed with the flows)
Edited
like-fill
1
  • reply
  • like
I mean. The prototypes are instances of the static...so it's not that big of a deal. The flow is just separate, and allows us to focus on each page rather than constantly dealing with the big picture.
  • reply
  • like
You can always jump to the prototype, and see how it fits into the flow. And that way it separates your thought patterns.
  • reply
  • like
Allowing you to focus on microinteractions, accessibility of this view, colors, etc.
Edited
  • reply
  • like
I always find it very hard to share just the prototypes even with devs that know the flows. they lose context pretty quickly, when they need to go back on the prototype, they get lost and some pages are not in the right order if you just click left and right on the keyboard. And, also in the context of making changes and iterations, I tend to always show the context of the screens with the flow
  • reply
  • like
Show more messages
private
This channel has been archived