▄▀▀▀▀▄    ▄▀▀▀▀▄   ▄▀▀▀▀▄   ▄▀▀█▄▄  
█         █      █ █      █ █ ▄▀   █ 
█    ▀▄▄  █      █ █      █ ▐ █    █ 
█     █ █ ▀▄    ▄▀ ▀▄    ▄▀   █    █ 
▐▀▄▄▄▄▀ ▐   ▀▀▀▀     ▀▀▀▀    ▄▀▄▄▄▄▀ 
▐                           █     ▐  
 ▄▀▀▄ ▀▄  ▄▀▀█▄▄▄▄  ▄▀▀▄    ▄▀▀▄  ▄▀▀▀▀▄ 
█  █ █ █ ▐  ▄▀   ▐ █   █    ▐  █ █ █   ▐ 
▐  █  ▀█   █▄▄▄▄▄  ▐  █        █    ▀▄   
  █   █    █    ▌    █   ▄    █  ▀▄   █  
▄▀   █    ▄▀▄▄▄▄      ▀▄▀ ▀▄ ▄▀   █▀▀▀   
█    ▐    █    ▐            ▀     ▐      
▐         ▐                              
Welcome Back
Enter your email address to receive a sign in link.
Email Address
Good News
A community for designers.
·Sign In·
Request Access
What Figma organization model worked best for you?
* * *
* * *

Hey y'all,

Our team has been growing and we're trying to figure out the best way to organize our files. Our goal is to ensure Figma matches production, files are easy to find and navigate (especially to new team members) and to minimize clashes between people. We arrived at 2 possible solutions:

1. Spec & Feature files

Spec files are sources of truth that match production. Feature files are where the work happens. When features are done, Spec files are updated so they match the latest.

  • We tried this and it requires a lot of discipline to keep spec files updated.
2. Branch & merge

We have a file per area of our product and use Figma's branching functionality; when we're done, we merge back into the main file.

  • We've been trying this out, but certain projects touch on different parts of the product, and we're finding that often we have to create "feature" files for prototypes that show how it all comes together — eventually these become the main working file and we have to go back and manually update the branch — bringing us back to the first solution.

How do you and your teams handle this? What has worked best? We are eventually growing to about 20/30 people, keen to hear from folks at bigger organizations.

Rodrigo Tello
* * *
Visible to the outside (?)
Request access or sign in to reply.

I don’t have a better answer for you. What you’re doing sounds reasonable/hard. I have seen teams struggle merging changes that come from Jira cards back into the trunk and just end up moving on to the next task because the org doesn’t budget time for design to be organized. That means many times there is no source of truth to fall back on, and subsequent changes can be confusing and incomplete which can be costly if other designers try to pick things back up and have to piece different designs together or make errors because of the separate files.

I think it boils down to whether your company understands the importance of design and gives the team the time and space to do what they need to get organized. You’ll probably also need somebody to champion your cause, somebody who felt the pain, because this sort of stuff is hard for the rest of the org to wrap their head around if they’ve never lived it.

Ps: I like your About.

Pps: Did you know that Flash used to be called FutureSplash before Macromedia bought it? Perfect moniker for the things to come.

Thank you for the reply. Merging back changes that happened on the fly in development is also a problem we've struggled with. We found it's all about discipline & creating the space to do so, as you suggested.

Also — I did not know that about Flash! My first version was 3.0 & always assumed it had been made by Macromedia! Time to update my bio, I guess 😅

Things go around. Do you know that Final Cut was made by one of the early Adobe Premier creators at Macromedia, before Apple bought it. ;)

· · ·
Victor DIndustrial UX Designer at
2 mnths ago

Hi, Just some random thoughts. I don't know if I'm answering you :) Edit: now I'm reading better your question. So no, I'm not answering it at all :P

I would try to simplify a bit the process. Having specifications, implementation and design might be too much. Could you have the specification as part of your design or your implementation? Tools like Storybook help a lot to bring specifications aligned with the implementation. Having 3 things that you have to update each time might be tedious and error-prone.

If you are trying to catch up with the implementation, I would make the source of truth the code. Then later you might re-balance and give more weight to the design.

Just have in mind that it's way easier to change things in Figma than in code. So depending on your team, priorities, and resources you might consider code or design the source of truth.

A directory with links to all the up-to-date resources is very handy to have.

Design and code people should talk to each other but don't necessarily need to follow the same workflows. Branching and merging work great with code. Not that great with design workflows. Versioning also still sucks in the design world. Most people still duplicate files and rename them to _1, _2, _final, _real_final, _real_final_2 :)

When you work on the design you might work in a structured or unstructured fashion. design system vs experimentation. Having freedom is important.

Talk early with devs. I've seen countless designers that create a design and expect that to be implemented. Sometimes time, dev resources or even lack of understanding on how to implement things prevent that to happen.

ps: I tried to use bullet points but here is not margin between text blocks so It made the whole text EVEN more difficult to read :)

About Good News
Good News is a community for designers and other product people. We celebrate one another, share accomplishments, assume good intent, and reject cynicism.
© 2022 · Release 0.1.4Folks Logo