The Design System or Library in Figma is a critical tool in scaling your operation beyond a single designer and project. Like everything, it can be done well or poorly. It’s all about the details. My best version of this was at Treasure Data where it was the backbone of all designs. Tiffany Trinh led the development and has become a world-class expert on design systems in the process.
Note: This article assumes Figma but might be applicable to other systems. One could write an entire book on this subject, so expect this to be a limited overview.
How to Approach the Process
Like everything I do, I approach the design system as a designer. There are personas, goals, and elements to consider. Before you begin, you should look at the designs people have done in your company and understand all the details of their world.
Additionally, you should imagine a designer being able to build a UI completely using only components, variants, and changing text. This is a high bar, but it has magnificent benefits. It means your designs will be consistent and pixel perfect without having to do anything special.
The goal is a design system is to make it so a designer can make a new feature with only existing components.
– Glen Lipka 2019
Start with Color and Fonts
Figma styles are good to start because all of your components will use these colors and fonts. Make the fonts based on real world usage. No need to have a style defined that is never used. I like to name them what they are as opposed to code names like “Title” or “Button”. If it helps differentiate for a user can combine and put those words after.
I recommend 36 colors and arrange them so that when you choose a color they look organized. See example below.
The truth is that 90% of the time you will use about 6 colors. Make sure those ones are easy to identify.
Atoms, Molecules, Animals
Obviously, everything in the Figma Library is a component. There is an art to naming. Making sure people can find the components naturally. We organize our system into different sized elements.
Atoms
Atoms are tiny parts of a UI and generally should not be used by themselves. This includes buttons, checkboxes, input fields, labels, etc. Make your atoms simple. Don’t have too many layers. In fact, try and have as few layers as you can. Use variants in your atoms to have different states. (Checked, hover, clicked, etc)
Molecules
Molecules will do more heavy lifting for you. These are pieces of the UI that combine atoms and can be used to construct UI. An example would be a form element that combined a type of input (atom) and a label (atom).
Animals (Or organisms)
Animals are complex objects that combine multiple molecules. This “Farm” metaphor was explained to me by Chudo Loo (excellent designer!) in 2016 and I have adopted it ever since.
The Farm Metaphor
When you have a farm, you don’t want 8 different kinds of cows. It makes maintenance harder. In a UI you don’t want 8 different kinds of buttons. It makes maintenance harder.
When you add a new animal to the farm (a.k.a. new UI pattern) all of the designers (and a UI engineer) should be all in agreement with the addition. Consistency is often better than adding a new animal. (See blog post) In other words, don’t allow too much variance in the UI.
Icons
Make sure the names of icons are easy to search/understand. I like to use variants to keep the number small, but Figma does not show previews of the variants, so you might want to keep them flat.
Make them all the same size with their constraints set to “scale”. You don’t want them to be different sizes all over the place.
Meta Elements
I use a few meta elements to go on top of designs to keep notes or explain things to engineers. Include a sticker and a sticky note like the example below. You might have variants for the purpose of coding like high priority might be red.
Autolayout
Every designer I know learns about Auto Layout in Figma and then proceeds to use it WAY TOO MUCH. You know it when your components has 4+ layers of nested auto layouts with just one element in each layer. I’ve seen some go 10 layers deep. No one can figure out how it works when you do this.
It is a powerful feature and is critical to success, but be careful not to over do it. Remember, fewer layers is good. It loads faster and is easier to debug when your prototype acts incorrectly.
Base Pages
The most important component is the base page. This is what every single design in your application will be built upon.
Every page in the design should be the same height and width. I use 1333 x 750 for desktop applications. It forces me to fit things without scrolling on lower-end machines and tablets. Additionally, that is a perfect 16:9 ratio, so I can paste into a presentation and the image will fit perfectly edge-to-edge.
You can use scrolling in your designs, but force the designers to look at a cramped base. It’s good design discipline and keeps your app from becoming too noisy/crowded.
Nested Components vs Variants
There is no absolute answer here. Sometimes it’s better for the designer to go down a level and change a component. Other times, you can use variants and do it automatically for them. I use both methods. My rule of thumb is to figure out what is the easiest to build and maintain. If it takes forever in the design system maintenance, it may not be worth it.
When I see more than 3 properties on a single component, I get uncomfortable. Try and keep it to 1-2.
Prototyping
May designers don’t do this, but I think it’s important. Always show your designs in prototype mode. Do not show your canvas. It’s messy and confusing and makes it hard to show users in research. Put in the extra effort and make it clickable. The design system is here to help with that.
The Approach (again)
Remember, you are approaching this as a product designer. Your “user” is the designer. They should be able to make a feature using ONLY components, variants, and text changes. They should never be adding new animals to the farm without a group conference about it.
An engineer will always say “it’s possible to customize” but you need to be disciplined. Every new animal or variance from the standards mean that engineering may be putting in custom code. This is pure technical debt. Never allow an engineer to change something for “just this page”.
Evolution
Your design system can not remain static forever. New features are introduced and new requirements or use cases show up. You need to constantly look at the system and make sure it stays current. In other words, pay your UX debt as you go. A design system should be evolved at least twice a year and overhauled once every 3 years (maximum).
Note on cleanliness
Name your layers! Keep things clean! It’s a sloppy designer who doesn’t name their layers.
Summary
Even though this is a long post, it just scratches the surface on a good design system. It’s like writing a post on what makes a good application. It’s just too big. However, I had these thoughts on my mind and wanted to at least give an overview.
I hope it helps you. Merry Designing!
Whatya think?