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 11, 2019 at 11:40am
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
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 :)
Edited
  • reply
  • like
Yeah. I've been aggressive in promoting that they not left and right press on keyboard. I educated them by putting empty slides in that said to not use error keys. After seeing that a few times, and chuckling they learned to stop doing it.
Edited
like-fill
2
  • reply
  • like
private
This channel has been archived