I’m going to start writing a bit about design starting with design systems. I have a bunch of notes and articles and I want to organize my thoughts so what better way to do that than in public.
It’s probably going to get a bit messy and confusing but hopefully something good will come of it.
The oldest example I’ve seen used as an example of a design system is the signage and visual design of the #tokyo #olympics 1964
Since a lot of the visitors where unfamiliar with Japanese they needed to create signs and messages that were understood by everyone. The fact that they did this in a cohesive way is why we describe it as a system of design.
On the occasion of Olympic Day, celebrated each year on the 23rd of June, we dive deep into the branding of the world’s biggest sports event as a reminder of the trailblazing work of Yusaku Kamekura...
Today, if you work more on the #brand or #marketing side of design, you might run into this meaning of design system. Usually we mean a system of logos, type, color, and messages that can be combined for presentations, decorating, merchandise, etc.
This is often described in a #brandbook or a #styleguide
If you work with tech and software you might sometimes encounter this type of DS but usually we are talking about something else
If you work with #frontend in #tech today and someone says design system they probably mean one of these things:
#styleguide
#UIkit
Front end framework
“Design system”
I’m putting DS in quotes since that is precisely what is being argued.
Some or all of these things (and more) can be a part of a design system and I will go through them and try to explain to you and to myself what they are and why it is sometimes called design system
Style guides are usually found in brand books and lists the official type and fonts, the brand color and maybe a pallete, and general guidelines for how to use them. A lot of space is usually devoted to how to use and not use the logo, something that is often completely missing in style guides for web.
This guide can be considered a system since it contains building blocks and rules on how to combine them.
The content is also usually incorporated into more techy design systems
The content of a #styleguide is quite often used as atoms or primitives in a #DesignSystems and are usually stored and managed using #designtokens
I will get back to all of these terms
Back in the day, 2015ish and earlier, most web design used to be done with photoshop or illustrator (at least mock-ups, we can get into the details of this later).
To speed up work (I haven’t heard people talking about consistency that much which is wierd since design systems always mention consistency) designers would have premade file with common elements like buttons and input fields that they could just drop into the design.
This was the UIKit
In my experience and opinion most of the time when you work as a #ux designer you will be working with a #UIkit and not a #DesignSystem
Many companies simply copy materialui or the ANT design files in #figma add their brand color and call it their design system. Developers implement it with tailwind inline css and that’s that.
I think this is fine but it would be great if used clearer terms for it.
IMO design systems should have reusable components
Sometimes the #UIkit is called a Component Library but sometimes a component library is chunks of code that developers use to build the app/website.
If your component library is the kind with code we are getting very close to a design system but there are a few things more we need...
So finally we get to what many articles assume when they speak of #DesignSystem
This kind of DS is built up from atoms, to molecules, to organisms, and onto templates (and maybe further into pages and who knows what). This stuff is stored as code either in a directory or in some kind of support solution like #storybook
A DS might even have values, guidelines, principles, and processes as part of its content.
Let’s walk through it:
Brad Frost literally wrote the book on atomic design systems https://atomicdesign.bradfrost.com/chapter-2/
The takeaway from the metaphor of atoms, molecules, etc. is that something basic can be nested inside something more complex.
Frost use the example of HTML elements as the most basic atoms but, as I’ve pointed out before, many DS are actually UI kits atoms are often things like colors and typography
So the primitives or atoms often comes from the #styleguide and brand book. That is where you will get things like #typography and brand colors.
Make sure to check if these work on the web/app. Some things to look out for: is it a font with enough weights for the use you have? is it readily available or will people need to download it? For colors look out for if it will work with state colors like red or green (I've worked with a lot of pinks which can look like warnings if you are not careful)
There are a couple of ways you can work with these atoms like color and type.
One way is to make them into "styles" in #figma and then when you do your design make sure to select these styles instead of picking colors with a color picker for example.
Another great way to work with them is through #designtokens
#designtokens are simply key-value pairs that you keep somewhere for reference.
If you write your button like this:
.button {
background-color: : rgb(0, 123, 255);
};
You might be inconsistent and if you ever want to change the color you could have thousands of places to update.
Instead store it like a variable:
// designTokens.scss
$primaryColor: rgb(0, 123, 255);
And simply reference it in your button:
import 'designTokens';
.button {
background-color: $primaryColor;
};
I'm sure there are a lot of things to say about design tokens. Something i think is quite important is the naming of the tokens.
Here are some articles i have saved concerning tokens:
https://danmall.com/posts/design-tokens-resources/
https://blog.prototypr.io/design-systems-token-configuration-breakdown-6eca6e5b8a3f
https://didoo.medium.com/how-to-manage-your-design-tokens-with-style-dictionary-98c795b938aa
Amalgam