Organising Design Work in Figma — A Systemic Guide and Framework
For digital designers who want to organise their working files to improve clarity and collaboration within and across teams
Update: Version 2.0 is here with new components and detailed documentation. Version 1.0 is still in operation.
The need for order in the chaos
As designers, we work with chaos. By chaos, what I mean is the way we get to come up with solutions for real-world problems. Whenever there’s a challenge to solve, we first try to understand if the challenge exists for real people, and if it does, we think about the intricacies of the problem at hand — like the viewpoints that are not surfaced at the top, the un-obvious elements at play and so forth. With enough understanding of the problem, we move on to finding solutions as the next step. This step is the messiest of the lot — there are no definite ways to arrive at the right solution other than to experiment aplenty and iterate on those that satisfy the needs of real people.
As a designer, you will also be using different design methodologies, and tools at every stage of the design process to figure things out. Sometimes, there is a need for divergent thinking and sometimes to converge. The job of a designer then becomes about how to approach a problem to arrive at a suitable solution — and these approaches aren’t linear or straightforward.
Thus, we establish that chaos is inherent and in fact enriching our everyday design work. Now that we are well aware of the chaos in the process of design, it’s time to confirm why we need order alongside the chaotic nature of the work we do.
Situation 1: Let’s say you are trying to find something that you are looking for from the dozens of design iterations you have made. Unless you have a photographic memory, it is easy to lose track of things after a while when you start working on multiple projects.
Situation 2: Let’s say the screens you have designed are in review. Someone from your team wants to offer you feedback on the designs you’ve made, but they find it difficult to navigate the file you’ve shared with them. They are also not sure of the nature of feedback to offer — functional or visual, in-depth or casual.
Situation 3: Let’s say someone from outside of your team is accessing your design file. They can’t seem to find enough context about the problem that you’re trying to solve or the research that you’ve made to arrive at the solution at hand. It limits them the opportunity to find inspiration in the hours of work you’ve put in.
These and plenty more of such situations that occur with every design project necessitates guidelines for organising information (for lack of a shorter phrase). To better view, navigate, and digest the information by everyone that’s involved in a project, we need systems in place that can provide structure to the chaos. This means that we find a place for everything (including a place for disordered data) and have the available information described and connected well enough for future reference for everyone.
In this article, we will look at how to go about solving this ‘organising information’ problem in a systemic way.
The bottom-up approach of organising information (using Figma)
First-order of information
Every task that we carry out as designers result in data (aka output) that’s associated with the problem we are trying to solve. Let’s take an example that can live through this article for easy reference and explanation. Let’s say you are asked to come up with research and designs for a personal finance management application (single/multiple members can be working on this project).
All of the output of this initiative belongs to the first order in the information structure. These include the research documents that we come up with, competitor research screenshots, solution explorations, the final design screens themselves, prototypes, UX audit screens, and so on. Think of them as the individual pieces of information that are ultimately looked up by anyone, but unclassified.
Second-order of information
In the second-order of information, there is information about the information (metadata). This means it provides information about the output we have come up with. In the context of Zeta (a payment-focussed company that has numerous initiatives), we have devised two types of metadata called Projects and Activities.
Projects are the higher-level metadata that gives information about the initiative at hand, which includes relevant documents, people involved in the project, its goals, and related information. There can be different Projects for an initiative while designing a personal finance management application. For example, ‘research and designs for Savings’, and ‘Tax Management’ can be two (or more depending upon how you’d like to segment) Projects within the same initiative that we picked. Similarly, designing the screens for the ‘Indian market’ and the ‘US market’ can be two different Projects under the same initiative. The Project information is present on the first page of the file as it provides the best overview of how the work is segmented inside the file.
Activities are the lower-level metadata that gives information about the work-streams or the different tasks that we do to complete a Project. All of the Activities are linked to their respective Projects with current statuses. Activities can begin with research and end in usability testing depending on what’s needed for a project.
Third-order of organising
Activities can further be grouped into design stages. At Zeta, we have primarily broken down the process of design into 3 simple stages. Understand, Build, and Test. Everything else like Overview, Local Components, Style Guide, and Archive are given their respective places, separated out from the design stages.
Understand
This stage has Activities that are taken up during the initial stages of design before they get picked for development. Like User Stories, Competitor Analysis, Journey Mapping, Information Architecture, and Mood-boards.
Build
This stage has the designs, prototypes, and presentations that will be used by the development/sales team for building the product/sales pitches. This stage covers the output of the Activities that are intended to be picked up for screen design discussions and development. They also include initial design explorations.
Test
This stage has all of the Activities that involve maintaining the quality of the end results from the Build stage, including UX Audits, and Activities that gather usability data on the designs or the research made. Measurement is key to any design process and this phase is dedicated to Activities that contribute to evaluating the design work.
Derived principles for the guidelines
With the multi-order approach of organising information in place, we came up with components that we found good use for. Looking back, there are certain principles that we focused on to come up with better guidelines and components for organising information in the design files. Let’s take a look at them.
1. Flexibility to cover current use cases of initiatives
The initiatives at Zeta are varied in nature, like how it is in organisations that work on multiple aspects of design. We are not always designing an application. There can be diverse initiatives such as branding a product, adding a feature to an already existing product, and so forth. We wanted to make the guidelines work for all of the initiatives that are available currently and those that we can foresee with our current knowledge.
2. Uniform vocabulary
Having a uniform vocabulary in the guidelines such as the notion of Projects and Activities helps build a cohesive understanding within the organisation whenever the files are being looked up by someone.
3. Ease of implementation
Some of us still think of organising information as an optional step. The benefits of organising can be huge for digesting information by other stakeholders (and ourselves) at any point. To reduce the efforts of the designers to sort out the information, we’ve created modular components and page templates that can be quickly implemented by copying and altering the text. This has made sure that the time it takes to organise and annotate is significantly less when compared to implementing an organising approach from scratch. There are also written instructions on how to segment Projects.
4. Accommodation of all stakeholders
Each one of us involved has different needs. Developers like to see the details of interactions and the visual elements. Product Managers and design reviewers need an understanding of which files to review and what type of feedback to provide. Design peers like to read the documentation and offer notes. Designers themselves like to be assisted with a checklist of things to do before wrapping up a project. We need to ensure that all of these use cases are easily executed using the guidelines system.
5. Room for continuous improvement
There’s always room for improvement for the guidelines to evolve. When someone faces an anomaly while using the guidelines, they need to feel free to share their feedback so they can be fixed in the upcoming versions. Our designers offer comments about the components that aren’t working well for their particular use case.
These guidelines are called “guidelines” for a reason, they are not strict prescriptions but are good frameworks to follow for maximising the design outcome.
Bonus outcomes of practising the guidelines
- While practicing the Project and Activity notion, we have progressed in quantifying the work in terms of which business/user need constitutes a Project in the context of Banking in Zeta. This outcome helps with identifying the resources, knowledge gaps, and tasks that are required for completing a design initiative.
- While presenting the work to our teammates or others (which we do regularly in our sync-ups), it has become easier to highlight the importance of a Project or Activity without having to open multiple tabs of documents. As the work is thoughtfully organised, it presents itself better.
- Developers and Product Managers can see the statuses of the tasks that are in progress, by not having to ask the designers every time. They communicate their needs accordingly, based on what’s visible on the files. Thereby, we’ve improved our asynchronous communication, which is one of the dire needs of working from home.
In conclusion…
The future of our guidelines system will involve testing the notions with all of the involved stakeholders and seeing if there are ways to improve.
We have come to the end of the article. If you’re still not convinced about having a guidelines system in place for your team, let me ask you this. Which do you think is useful — an unorganised bunch of pages with information that is not cohesive or a book that is filtered and sectioned appropriately for the pleasure of your reading?
Taking ten minutes to make design files less overwhelming will create a monumental change that’s built for scale in terms of effective knowledge absorption and collaboration.
If you are the only designer who has the access to the knowledge of your design projects, it’s time to spread your wisdom to others through efficient organisation and annotation of your design files which will be heavily beneficial and interesting to others in the team. That’s the genuine pitch.
Thanks for taking the time to read! I hope you found this article valuable. If so, do let us know in the comments! Feel free to access the community file (to duplicate) that has the components discussed in the article. You can improve them based on your organisation’s needs.
Feeling thankful to Mustafa Quilon, and Zeta’s banking design team for the help and assistance in the creation and adoption of the organising guidelines. Thanks to Femke van Schoonhoven, Mixpanel designers, and the Figma community members for inspiring us to work on this project through their own file organisation initiatives. ❤
