Figma is the first collaborative UI design tool built in the browser. Join our growing community and kick off a conversation!
J A S O N@jscottpearson
Show previous messages
Version ControlFebruary 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?
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 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.
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.
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
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
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 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.
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
but that's fine, I just want to understand how others do things. Until today I've always been the only designer in the teams. tks for sharing :)
This channel has been archived