A design system’s first steps
If you are working on the early stages of a design system, you might not know where to start. Either you’re working with an existing product, and need to “retro-engineer” a design system from it, or you’re starting from scratch. There are a myriad of great articles that can walk you through this adventure, and a ton of companies that have produced some of the most robust design systems to take inspiration from (Google’s Material/IBM’s Carbon/Shopify’s Polaris…). But in my opinion, there are two things to be real careful about:
Make the design system fit your needs.
Unjustified complexity in your design system will always become a problem. If something is useless, then all thats left for it is to bring trouble. Your design system, in itself, must be a minimal viable product. Keep it as simple as possible. A good way to determine if something in your product is useless is through absence testing: if you’re having doubts on the purpose of something, take it down. If nothing happened, then you can keep it that way.
A design system helps bring the designer as close as possible to the front-end developer. In that sense, both parties need to settle on common ground, and one thing you can’t take away from developers is structure. Every front-end team today uses tools that allow for blazing-fast and stable development, at the cost of one thing: structure. Whatever you add to that structure will make it heavier, and more failure-prone. Ever been on a wobbly 4-legged stool ? Take one leg off, bend the 3 legs to form a triangle on the floor, problem solved!
Get the first few fundamental things right.
Initializing a design system correctly can really save some time working on design and technical debt. If your structure is right from the start, then it’s much easier to pivot and adapt stuff in the future. The 3 key elements of our design system—the “atoms”—are Color, Spacing, and Typography.
Here’s what these three pillars look like at Brigad:
1) The Color System
Here’s what our first color palette looked like:
In this color palette, the only thing that defined a color was its hex code. They were named after the actual color they were. But this approach has two flaws:
- Imagine you have an x-dark-grey text, and for some reason, it’s not dark enough. You can either create another color xx-dark-grey, which adds complexity (no bueno), or directly change the value of the color x-dark-grey. The problem is you also had a background pointing to that same color, and now it’s too dark. Things can get pretty messed up.
- Most of the time, as a designer, you never really know which color to use to stay consistent. You try to replicate patterns without really formalizing them.
So we transitioned to this:
The key difference between the color palette and the color system is the definition of a color.
As much as possible, a color is defined by its function in the UI rather than the color itself (apart from the elementary colors, whose sole functions are to “be themselves”). Here’s how we benefit from this system:
- You always know which color to use, because their names are self-explanatory.
- If ever we want to change a color in the future, we can do it super easily because we know exactly what will be impacted.
However for this to work well, it’s important to spend enough time thinking about what you should consider being a color, and find a good balance between modularity and simplicity.
Also, because all our colors are now uncorrelated and secluded, it can be hard to maintain harmony, which is why it is always good to base the colors’ hex values on a color palette.
2) The Spacing System
Ever found yourself Shift - ⬆⬆⬆ ⬅➡⬆⬇-ing for ages until you find the right spacing? Moving things around until it looks right? The problem is there is a part of randomness as to what we find aesthetically pleasing, and remember, developers want structure. If you’ve decided to set a 10px margin here, a 12px margin there, 6.74 other there… and ever find yourself justifying these decisions to a developer, they might be like:
bruuuh…
Because it’s frustrating to have millions of constant values like these scattered around your code. What you want is a neat little framework that tells you what to do, in any situation, and allows you to bring everything down to a single true reference.
Similarly to colors, there are no right spacing values. You just have to settle on something that looks good enough, and stick to it.
Here are a handful of neat articles I’ve read, and have guided me through the creation of a first version of a spacing system:
Some of these articles mention beautifully designed spacing systems, where spacing values are programmatically generated based on the ex-value of the main font of their styleguide. I loved it, that people had managed to formalize something that none of us really know what to do with—spacing.
But it was too complex, we didn’t need such performance.
So although some of these articles look like PhD papers, two accessible things stood out:
- The 8-point grid
Everyone’s talking about it, why not use it? 🤷♂️ - The Golden Ratio (1.618)
Helps with information hierarchy. For some reason, if something has a size of 1, and something next to it has a value 1.618, it looks harmonious! 🤷♂️
So here’s what we have for spacing values :
And here’s how to use them!
Now to be perfectly honest, this is more of a guide than a framework. It’s far from perfect, and almost impossible to consistently respect, but at least it helps you understand why you have used this or that value, which is the first step towards creating a system.
3) The Typography System
Now this one is much simpler, I won’t go into too much detail because it doesn’t differ much from most typography systems, apart from one thing that’s seldom considered:
Line-height
The line-height is the real height one line of text will take up. It’s a css value, and it’s important you line up the line-heights of your designs with the line-heights the developers will be using in their code.
Default line-height is somewhere around 1.4, meaning it takes up 140% of the font-size. You can also push it up to somewhere around 1.6 (Golden ratio 🤯) for a more harmonious spacing. Whatever you choose, you must be aligned with the developers for them to specify it in their css, or else browser default will take over (which isn’t necessarily your design tool’s default).
You can also specify pixel units for the line-height, and that’s what we did.
Notice anything?
All the line-height values are contained in the values of the spacing system above! And for the Title and Body typos, the (line-height)/(font-size) ratios are 93% and 82% close to the GOLDEN RATIO.
Conclusion
We are still in the testing phase, but we are expecting this first framework to reduce time and randomness on low impact design tasks, along with guaranteeing consistency throughout our product.
The next steps are to broaden our design system to any element of the product that can be formalized: tone, animations, user flows… All of these will serve the same purpose of improving the performance of the product team.
Thanks for reading!
