Spectrum is now read-only. Learn more about the decision in our official announcement.


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

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
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?
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.

February 8, 2019 at 9:06am
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.

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.
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.
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.
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.
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.

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?
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.
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.
I had similar questions here 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.

February 11, 2019 at 11:12pm
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.

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
On your Verification Page, do you display the UI screens mixed with flows? see pic please
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.
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.
Micro-Interactions (when needed are done later, and reference the prototype clickthrough when needed)
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)
I mean. The prototypes are instances of the 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.
You can always jump to the prototype, and see how it fits into the flow. And that way it separates your thought patterns.
Allowing you to focus on microinteractions, accessibility of this view, colors, etc.
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
Show more messages