Welcome to the Figma series brought to you by Design at Scale™ Academy(↘︎Link). In the last article, we explored what role tiles play in Figma visual discovery and how we can improve the findability of all our digital assets in Figma space. Now, on to an even more exciting topic: the Figma file structure.
Why does it matter?
Before we proceed, I’d like to highlight two of my previous articles to give you some context on naming conventions and why we should really care about these little details: The Power of Naming Convention(↘︎Link) and The Impact of Naming Convention on Delivery(↘︎Link).
Countless articles, social posts and other references suggest that we have two camps of people – people who name the layer and people who don’t. People who do claim it's important to have very little to no ammunition to back it up and explain why it is beneficial. On the other hand, the production machine claims that we do not have the time to do it at all. We‘d rather copy and paste.
Let’s look at the theory first. Every average designer knows how the basic component works and how quickly you can change the 100+ buttons across the proposition – that is easy. Inevitably, if we link all of our components correctly, we should be able to control our experience within the Design System and, therefore, have a safe time.
The ultimate challenge with this theory is designers' pressure and lack of time or proficiency. In the production line, we need to act quickly. Time is a commodity that is greatly wasted on meetings rather than creation. Therefore, the average skilled designer is not going to craft 200+ components with a boolean value to finish a daily task; it will be simply copy-and-paste.
Do not worry; I’m guilty of that, as are any other designer out there.
Luckily, like a few designers, I had a chance to experience a fully connected design system in 2005 across many different design software solutions like Adobe InDesign and Photoshop in 2013 and from 2017 in Figma. Since 2020, I’ve invested a great deal of time in studying automation in Figma, and I must say, if you do make sure that you create and well document a Design System that is correctly integrated with your proposition, you can easily replace 10+ people (who copy pasters) in less than a month. The caveat is that you’ll probably need to pay the DS girl/boy 3-5x times more than you pay basic diggers. (this is an altogether different topic)
DaS™ Structure
The below structure is nothing specific or profound. I have changed it several times and am constantly evolving as we go. The main thing is that it reflects feature-based product design development(↘︎Link) and is compatible with Atlassian integrations(↘︎Link). In very few instances, I have had to adopt a different structure, and I’m proud to say that several SMEs and even some big corporations have adopted this structure until today. The master file is available at Design at Scale™ – Supply(↘︎Link).
DaS™ – Welcome
Each file has a tile with the description mentioned in the previous article(↘︎Link). More importantly, it has a version table where we summarise the daily changes and increments—including date, action(↘︎Link), status(↘︎Link), blocker(↘︎Link), and delivered(↘︎Link).
DaS™ – Reference
The second stage usually compiles all our research. In some cases, we have two separate stages: one for external research, which is competitive analysis, and the second one is internal research, which is how we tackle the feature today and what we want to change. I keep only necessary files for the specific feature, search, which refers only to search patterns, pages and suggestions in search results. The file does not include anything else apart from Search-related supporting data. In some cases, especially more branded propositions, we introduce the stage for the Style – inspirational mood boards and ideas that we can safely carry over. More about references at Design at Scale™ – Creative Community(↘︎Link).
DaS™ – Findings
The fourth stage is looking at all the previous work that we have done in a similar project—previous iterations, similar work, or someone less internal testing for the same behaviour or feature. This is always better than starting from a clean sheet of paper. First, it gives you credibility and articulates continuous od instead of “this new thing.” Equally, this allows you to check if everything is well connected to the Design System properties and works properly.
DaS™ – CX
The CX stage was mentioned in one of the previous articles(↘︎Link). Its purpose is to have the appropriate User Flows(↘︎Link) or, better said, User Journeys (↘︎Link) alongside your designs. It would be ideal to have all the flow and error scenarios in one file representing the so-called Epic(↘︎Link).
Understanding that Agencies would rather work on a screen-to-screen basis, this might be somehow difficult for Agile teams(↘︎Link). One way or another, having the CX flow in the same file significantly reduces the need to click between different files and look for the answers elsewhere. Do not mention that your Jira ticket and Confluence knowledge base will also look at a file. So that everyone is less hustled about finding their thing. More about references at Design at Scale™ – Creative Community(↘︎Link).
DaS™ – UI
Welcome to the UI stage. Yes, the most profound stage in the entire document as we are creating UI design or design for a product or service. Let me digress a little. We all know that the feature is not just one or a few screens. For example, the notifications feature could have 400+ different variants that show different icon scenarios, colours, and text lengths. I’d suggest splitting the user screen flow and additional files in this case. I have often used Jira ticket numbering to distinguish the section from the rest, which proved very effective when looking for answers in Atlassian and vice versa. Finally, give us the final designs for the proposition.
I know it is tempting – Desktop, Tablet, and Mobile screens. If you design for mobile or CTV in one single feature, you can easily reach 300+ screens. How do we divide them, and why?
– proposition based
– feature-based
– channel-based
More about references at Design at Scale™ – Creative Community(↘︎Link).
DaS™ – Prototypes
My favourite is prototyping. We start with schemas and play with transitions until it feels right. Basic shapes and containers allow my team and me to articulate the behavioural model. Once agreed upon across the team, we’ll move to defining wires and tweaks in motion again. The final design seals the deal and creates the final product with the desired look and feel.
Three things that happen throughout the project are worth mentioning. First, very few designers start from the behavioural or navigational model. We simply got so used to copying and pasting different UI kits that we forgot to build something better, simpler, smoother and nicer. Depriving us the second important thing that is “communicating value proposition”. All designers roll their sleeves throughout the project to communicate the value proposition. Not having the prototype, we all start with “Imagine…”, telling the other parties to imagine the very thing that only we can see. And the last is integrated with Atlassians’ toolchain. More about references at Design at Scale™ – Creative Community(↘︎Link).
DaS™ – Motion
Motion is frequently integrated into the design system yet needs to be redistributed to specific features. In this case, you’ll look for a section/stage where you describe the motion.
It simply elevates the feature to a new level. Your prototype's final animation and transition could also reflect these motion principles and offer your engineering team the details that make their work even more impactful.
One might ask, “What is the difference between Prototyping and Motion?” The answer is rather obvious. Prototyping is the journey, and focusing on testing and motion is the outcome.
DaS™ – Keynote (Y23 v1.0)
In every organisation, small, medium or large, we need to broadcast the idea to a wider audience. This happens naturally - word of mouth, which is equally very slow and ineffective in carrying a technical message. Or we create a so-called token of trust – or summary of sorts, that we can share with other parties. This is anything between screens, graphs, Keynote(↘︎Link), PowerPoint(↘︎Link), Google Slides(↘︎Link) or, very recently, Figma Slides(↘︎Link). The token has a unique place (with the link) and can be shared and integrated across the organisation.
Yes, some heavily regulated environments will require O365 PP, while start-ups will probably push for Google Sheets—either way, you’ll be copying your work somewhere else.
I happen to persuade all my colleagues and partners to use Figma Slides. The factors are mutually beneficial, which allows all parties to control what matters. Designers control the design, layout, message, and product, whereas businesses control the numbers and communicate the value proposition. Both are kept in one location with an appropriate brand, the right message, and the correct data—everybody is happy. The master file is available at Design at Scale™—Supply (↘︎Link).
Happy scaling through design!
Hey, I’m Jiri Mocicka. A London-based Designer, Trusted Advisor and author of Design at Scale™ – A method that allows individuals to shape the future organisation through design. Grid Magazine – brings weekly articles about product design development. An Online Academy helps designers find their feed in teams of 01, 01, and 100, supported by Supply, a collection of digital artefacts that helps you become a 1% designer.
If you have a question or are hesitant to ask, join our Design at Scale™ Community to connect with like-minded individuals who scale design propositions.
