A quick guide for setting up a design system: Figma edition
How we approach the basics of building a comprehensive design system when facing tight deadlines.
Let’s take a closer look at how we can (and should) implement our design systems to lighten the load of keeping all elements organised as well as better onboarding for other designers.
As mentioned previously in my other articles, having an ‘explain once, works everywhere’ method is the best approach when it comes to an agency working with rapid deliverables. Therefore, I’ll stick to using as little documentation as possible.
I’ll be using Figma as it is our team's current tool at OOZOU. However, it still works anywhere else with a bit of a tweak here and there. You can always leave me questions if you wonder how to do that on your stacks of design software.
Create a reasonable file structure for your projects
A design file is perhaps the most important aspect of your work. After all, it’s what you’ll be living in throughout your project.
We’re faced with ‘to separate or not to separate’ a library dilemma pretty much every once in a while during our time at OOZOU. Here’s the team approach on it:
A. If you’re having a so-called short-term project, go with a Single file.
Don’t waste your time creating a library and link it to a single file you’ll be working on. You can always migrate it later into a dedicated ‘style guide’ library should your project grow larger in scope. Time is of the essence and you have to be practical in your approach.
Be mindful that the file will be harder to manage over time and could present some performance issues if the project went on for too long and involves many features in and out of the project.
B. If you’re sensing a big potential for growth. Build 1 or 2 libraries file.
It is recommended to try separating the file now and link them together. As there will be more variables at play, eg. Responsive Desktop, Mobile, PWA, and Native version of the same application.
Consider building the file structure where you have your UI foundation pieces (more on what this is later) on one file and (if need be) illustrations & exportable assets on the other.
C. If it’s time to expand. Pump it into a full-on design system!
Having both Desktop and mobile web apps and Native iOS Android with a CMS system? It is time you take on the glory! We usually do these practices with our bigger projects divided by either a platform it needs to be in (mobile, CMS, web apps, etc.) or features we’re delivering to stakeholders (settings, onboarding):
- Branding (consists of common elements such as branding, colour, font styles)
- Assets & Illustrations (with its own set of colour and effects expanding upon the main branding guidelines)
- UI elements & templates
- Design files (divided by feature like Home_Web, Mobile, Apps, PWA, CMS, and so on, or platform-based with multiple features, Language-based if doing multi-region app design)
Design Library
Our main UI Library (or libraries) will contain some or more of the following categories:
1.Foundation - Classic ‘building block’ elements where it dictates the overall structure of our UI elements. Which includes:
- Branding assets - Logo and its Tagline
- Colour Palette - The basic and extended colour swatch created using the Corporate Identity (CI) guidelines
- Font family - Contains font types and family used throughout the product. Because of how Figma handles font colour styles, we would also have a set specific font colour defined in here as well (using Text/ as a parent group)
2.Spacing options - The number of spacing options allowed throughout the system (for example, a system of spacing in a project could start with 4px, incremented by 4px, maxed out at 80px)
3.A style guide (Optional) — This page is a digested format of everything in the file wrapped up in a simple format for handoff. We encouraged all stakeholders to comment on anything appearing here in order to keep our (occasionally) messy working area separated from the presentation area
4.Assets — Any exportable assets and illustrations we made will be on a separated file. This is because oftentimes we would need a little bit more extended range of colours and effects to create these assets and we wouldn’t want it to clog up the core UI elements.
5.Component Library — Common elements used throughout the design. This is where we keep our base components and their instance
In some cases where the project gets larger and expands towards some constraints, it is common to separate the foundation file in order to pair it with different design components to be used in each working file.
However, these methods still produced some problems to be addressed
Components (or Symbols)
These reusable parts play a vital role in building and maintaining an engaging and useful design system. Without proper preparation, you might find yourself and your team stumbles across many inconveniences throughout your project. To alleviate this, we suggest you prepare your team by establishing a pre-project meeting before setting out to create a components library.
Step 1: Define your components hierarchy system
There’s quite a large part of Medium articles that mention Atomic design by Brad Frost. I found the method easily understandable but harder in practice because our team finds separating anything apart between Atoms, Molecules, and Organisms very difficult in practice.
To fix that, establish a universal ‘components’ system by remembering everything by its own name. Omit the grouping entirely and keep it in your mind when you’re reaching a certain limit of ‘putting components together’ for example, a set of 2 buttons aligned horizontally next to each other will be more than a component and will be named with a prefix called ‘Template/’ or something along the line.
This will help others while they’re searching for any established rules that have already been made. Avoiding combining the same thing again. Remember to talk it through with your team members and establish a general rule set that will help them decide whether it is a template or not. Everything else besides that can just be a ‘normie’ component.
Step 2: Decide on the system’s component override levels
Sooner or later you’re going to be building nested components or templates that can be overridden with other siblings to fit the context of the current screen (or state).
In doing so, you will have to plan ahead for a little bit and set out to maintain our systems of components. To put it simply, the team will have to balance out the 2 main aspects of components overriding: Flexibility and Accessibility.
- Too much accessibility (eg. 4 Master components for 4 different states buttons) we would find it increasingly difficult in maintaining and creating a robust system. If you have to edit the padding on a primary button 12 times, we pretty much are defeating the whole purpose of having said system in the first place.
- On the other hand, if the method contains too much flexibility (eg. 12 form states in 1 master components) it would be really difficult for others designers to understand what you’re going for and how it could work with (or without) each other. Which will result in inconsistencies and would require you to check around more often than you would like
The main idea is to find that sweet spot of implementation so it requires a lower learning curve for others to follow. While maintaining its flexibility with minimal maintenance efforts. Usually, that would be around 2–3 nested components for each Master.
If you’re aiming for even more flexibility and maintainability. Consider showcasing your team members the capabilities of your override-able components within the components area.
Versioning and documentation
Even though I did mention minimal documentation in the previous part, by no means you will still need a good note and reminder about your changes. After all, a few notes you put in to remind yourself and inform your team member could go a long way to preventing headaches 2 months down the line.
In setting up and maintaining the library effectively, I highly recommend you refrain yourself from deleting or making unnecessary drastic changes to any components existing in the system, unless you are 100% sure that it isn’t going to sabotage any part of your active work file. If you really have no choice. I strongly suggest you consider adopting version control for your library file.
Set a commit note rule
You can easily do this via Abstract if you’re working with Sketch. Just make sure you have people filling out meaningful commit notes
Figma, however, proves version control to be a bit of a challenging topic. As every person’s contribution to a file is considered the source of truth. It could become autosave chaos if you decide to revert or retract some of the changes made into a linked library file in your system.
I recommend using the ‘Save to Version History’ command for setting history points. Create a Commit Rule and have everyone abide by it. A simple example is to have a Start point where you create your own return point at the start of your work and create another Endpoint when you’re done for the day. I suggest putting in the name of the task so you know what you’re doing.
If you happen to be derailing from the original task’s purpose, Set another Start point before and after it so you can track it back if you find that something has gone wrong.
Save writing instructions for harder stuff
When working in teams, consider which part of the system would you like to be an ‘explain once’ part, and which needed ‘reminder’ for both you and others.
For instance, if your team has been working with only simple level components in all of their previous projects. It might be a good idea to showcase some override capabilities of your commonly used components on a library file itself. So that other team members don’t end up building a new one because they think it doesn’t yet exist in a system.
Remember to talk with your team and find out how ‘detailed’ they wanted the instructions on a file to be. There’s no need to spend your precious time writing things that people won’t actually read or already know by common sense.
Congratulations, you now got yourself a design system!
Lean back and give yourself a nice warm cup of tea. By now you should be ready to set up your design system to use on your next project! This is probably more than enough to help you ease your way into setting up a usable library with a good file structure preparing for expansion in the near future.
This article was originally published at blog.oozou.com
