Setting up our file structure in Figma
A little article about how we decided to setup our file structure when shifting from Sketch to Figma
About Zeelo: We’re the smart bus platform for organisations. We’re building the world’s leading smart mobility platform for organisations, enabling access to safe and sustainable transportation for everyday journeys.
Intro
As we started expanding the design team and continued to improve our design processes, we decided to shift from Sketch to Figma to make use of their features better suited for team work and design operations: more efficient components libraries management, collaborations features, file organisation, embedded developer handoff, the list goes on…
We now had the opportunity to start from a clean slate, and I used my learnings from the past 2 years of leading design at Zeelo to decide how to best organise our files and design system in Figma.
I hope this article can help you figure out what file structure makes sense for your own team.
Choosing a Figma plan
I thought it was very important to consider the context of the company and its design function before settling down on a file structure and a Figma payment plan.
Zeelo is currently a small company, 60 employees, with 2 designers working across 4 product lines. We can expect the number of designers to grow as the size of the engineering team grows and align with the number of products. At the time of writing I favoured the option where all designers have access to all design files (“Professional Plan” setup), instead of being split across multiple teams on Figma (“Organization plan” setup). Very often when a designer works on a feature it involves making changes to multiple products, therefore letting any designers access all the files will be key. It makes it easy to move designers around different squads to experience the company’s entire eco-system of products.
Workflow
I started looking at our existing work processes to find a file organisation that would fit our workflow.
- Brainstorming, system & user flow mapping, collect inspiration (currently done in Miro)
- Work through multiple options and progressively refine the solution
- Lots of feedback session and testing will happen until we reach a satisfactory solution
- Final design is signed off — goes to development — maybe some last minutes tweaks to be expected
- We want to save all explorations and decisions for future references
- Merge final designs into a core file to maintain overarching view of the product
This highlighted the need to divide our workflow into 3 file categories:
- Work in progress: the project is ongoing, a lot of analysis and exploration work is being undertaken. This file is shared with collaborators like Product managers to review ideas, and with developers when the design is signed off and ready to be implemented.
- Current state of our product: This is the source of truth, only showing what has been built in the product. I’m choosing to divide each section of the product into individual files to keep them specific to a part of the product and its multiple variants / edge-cases.
- Archive explorations and decisions: We need to save all the explorations created and all that hard work put into designing something simple. Many times later, we’d be wondering “Why did we make decision Y?” and try to go through our decision process, so it’s great to have all of this history saved somewhere.
Figma file structure and workflow
Step 1: Create a new “Working file” and activate the relevant component library depending on the product(s) impacted by the changes
Step 2: Lead the entire project from this new working file. Here we will use different pages to organise the following content, obviously using a healthy dose of emojis 🥳 :
- 🖼 Cover (An image to help users identify the file)
- 💻 Handoff (Final design specs ready to be shared with developers)
- ▶️ Demo (If you needed to create a prototype to showcase the new experience or for user testing)
- ✏️ Exploration (All the versions we’ve been exploring during the project, ideally including notes about why decisions were made along the way, for future reference)
- 👉 Flow (Analysis of the system, existing or proposed user flow)
- 💬 Feedback / Crit (A place to log the internal feedback but also findings from user testing)
Step 3: When the feature is finally released, merge the final screens into each “Core” file so that the entire team can keep track of what the product currently looks like, per section of the product
Now, why split the “Core” file into so many files?
When considering how to organise our files, I looked at two options: one file for each product, using pages to outline its many sections (e.g Rider iOS App), or one file per section of the product (e.g Rider App — Homescreen), using pages to highlight different variants of this section if required. I chose the latter for the following reasons:
- Best practices recommended by Figma is try keep files as focused as possible, so that when shared with collaborators they don’t get lost in a sea of screens.
- When your product’s sections are already complex (multiple states and variants), it feels a lot clearer to have a file dedicated to a specific section, detailing its many states and edge cases.
- Performance wise, Figma will perform better with smaller file sizes
- Using version history will be easier to use if each file focuses on a subsection of your product
Step 4: Save the entire working file into the Archive folder for future reference. We might consider adding a date to the file name to keep track of frequent iteration of a problem.
Design system and libraries
Zeelo, given the small company size, is already working on a large amount of products, and I segmented these products to share design systems to speed up our work and maintain consistency across the eco-system.
Passenger products
We recently started a big project to align the visual style of all our passenger facing products to offer a cohesive experience (iOS, Android, Web) and decided to be sharing as many components as possible, unless the platform definitely required a different approach. None of the components would ever be shared with our driver apps.
Driver apps
Even though the UI is very similar between the iOS and Android version, we are making use of native components to speed up development where possible and increase stability. We decided to host the iOS/Android components into the same file and where needed highlight platform specific components.
Portals
Zeelo has a few internal tools that are now using the same design system: Operations management tool, Routing algorithm tool, Client portals, Bus operator portals, … These highly functional web-apps have their own requirements optimised for the web, so again we decided not to share components with other products.
Brand
Since we decided that none of our libraries would be sharing UI components, we only decided to be sharing a Brand library across all projects to host primary and secondary brand colours, as well as logos, and perhaps later we will roll out a standard iconography across all products via this library.
Figma components naming structure
I also wanted to use this opportunity of starting with a clean slate in Figma to use a consistent component naming structure.
Components will be named using the standard Buttons / Primary / … structure. We’ll be using a maximum a 5 category levels to organise our components, with the “Theme” being mostly used on the Apps to handle the Light mode <> Dark mode switch (by putting this option at the end of the name, you can design a screen for Light mode first, then copy it and switch the “theme” to quickly transform this screen into its Dark mode version)
I hope this article was useful and will help you visualise how to setup your files in Figma. Obviously it’s only one way of doing it, specific to our company organisation and products, you may find another approach to be more suited to your own organisation. Good luck!
❤️ Follow me to be notified of future publications! I post regularly about Product design tips, Design Ops, Design management and User research. Thanks!
