How to structure your Figma workflow

This is the second part of two where I give an introduction to how Figma is structured for beginners, if you haven’t checked out the first part, you can read it here

Not too long ago I joined a startup team as the first UX Designer. I tried to look online to find the best way to organise Figma for myself and for the rest of the team which consisted of developers, product managers and other senior stakeholders.

My main needs were to:

• Provide clearer visibility to the wider team over design/development progress without having to rely on any third-party tools
• Keep a log of design changes to make sure that there aren’t any updates to a Figma file that has already been handed off to development
• Have a regular backups in case any changes need to be rolled back
• Have quick and easy control over who has access to what without manually inviting / uninviting team members from certain files

After some reading on how Figma itself is structured, and after some trial and error on what worked best for our team, here’s how I landed with it.

Team

I invited everyone that is a regular viewer or editor on the team to Figma — nothing too complicated there. I also suggested to the team to download the desktop version of Figma to have quick and easy access to everything.

Projects

I made use of projects in a similar way to a Trello board, with designs moving from one “Project” / status to the next.

This allows me to create ‘spaces’ for multiple files while having easier control over sharing permissions. Do the developers need to see a history of past failed iterations for a particular user flow? Does the CEO need to have access to the design system files? Probably not.

Below is a list of all the projects I created along with who has access to each:

Design System

This contains icons, typography etc… this was only visible to myself in the earlier stages but was later shared with front-end developers as it started to take shape to act as a reference to the components used.

In Design

This is where the crazy stuff happens and a space for me to have v15 of a design without creating a mess as I’m trying out different things. This is only visible to myself.

Team Review

Anything that is demoed to the team, as well as any changes following those demos live here. Everyone on the team has access to this and was encouraged to add any thoughts or suggestions by dropping in comments.

Ready for Development

Once a particular flow has gone through all testing and stakeholder reviews it is moved here. Once there, there shouldn’t be any changes made. I typically send out a final Slack / Email to check ‘Team Review’ before anything is moved here.

In Development

As the name implies, developers move things to In Development once they’ve been picked up.

Implemented

Anything that has been successfully implemented, including going through the QA process is be moved here by myself or the product manager after a development demo.

Files & Pages

As mentioned in the first article, Figma includes a version history for all your files. The way it works however is less than ideal in a few ways:

• The version history applies to the entire file and not to individual pages
• There’s no control over who has access to which versions
• Switching between different versions has a bit of a delay as it loads up, which makes comparing versions or copying something across different versions slow and confusing

Instead, I decided to create files for each user flow (for example onboarding, or changing account settings). These files are organised as:

• Major changes are included in a new file with a version number (e.g. 2.0, 2.1, 2.2 etc…). This new file would travel along the above projects workflow until it is implemented
• Minor changes are included as a new page within the same file. These are casually communicated to developers in progress meetings or on Slack.

Processes must always adapt

The above process has worked for our team for a few months now, but it’s not always the case that it will work for your team, or that it will continue working for ours. Much like any UX project, be flexible enough in your approach and incorporate feedback from your users (your team members!) on how you can better organise and communicate your work.