Over the past six months we have worked on a large scale design system. When we were nearing a big release, I wrote down some key lessons.
Don’t expect a magic deliverable. Just like there’s no such thing as “handing over the UX”, there’s no final deliverable when releasing a design system. A design system keeps on evolving.
The design system reacts to real user and product needs. You can’t just take an existing design system and apply it to your situation.
While there are parallels between most design systems, there are also vast differences between design systems. For example, every design system likely has a button component. Some design systems are focused on mobile usage. Others are a result of the need for a scalable enterprise-style UI that can show big amounts of data on large monitors. Being aware of actual needs helps you to make the right choices.
A design system is useless if there isn’t an agreement on the decisions made. Decisions cannot be made in a vacuum.
It is useful to keep a log of why a certain decision was made to avoid backtracking. This can be done in an issue tracker like Github Issues.
As an outside consulting party, this is one of our biggest challenges – to find the balance between our internal design discussions and the external needs (from users, product managers, front-end developers etc.).
Think about a page that states which fonts and which colors to use. Think about agreeing on a set of icons.
A design template with components in a single design app can be the beginning of your system – but don’t see this as the end deliverable.
There is much more work that goes into a design system than just having a clean design file with hundreds of components. The first file is just the beginning.
The decisions made in the design system need to have an external reasoning. There are often technical reasons why things are the way they are — for example, buttons are a certain sizes because of touch devices. Things might be the way they are because of project requirements, such as universal access. But besides that, there are choices that have to be made based on what kind of design a company wants.
In the book Design Systems, author Alla Kholmatova explains how to handle a workshop to define design principles.
One of the most important lessons here is that a design principle should ideally not be a negative when you reverse it. “Simple” becomes “Complex” when you reverse it – but nobody likes complex.
“Timeless” reversed becomes “Trendy”. Do you want to be “Fun” or ”Serious”? In both examples none of the two are bad; a definition of what you want to be is a great exercise within the context of a design system.
The “single source of truth” is the holy grail in the design vs. development discussion.
In our most extensive design system, there is a website that lists design patterns, but also colors, typography, icons and brand usage (this part is kind of like a traditional style guide).
We combined this with an implementation of static HTML and CSS components that became the base for the next level of implementation in React.
Keeping a part of the design system in static HTML/CSS makes it easy to use the design system with multiple technologies in the future and does not lock everything down to a single technology.
A design system is not an afterthought that you quickly make when the project is done.
In order for a design system to work, it eventually needs to become its own project. There is a reason that companies with successful design systems such as Github, Shopify and IBM have dedicated teams to work on the design system.
A design system has to be communicated. Depending on the scale of the project, there are different solutions, such as a public website, issue trackers, changelogs and a blog (or all of these).
In every team it needs to be clear where you should go to find your information. You shouldn’t have to hunt for some vague file on Google Drive somewhere to find the information you need.
In most cases, the best solution is a public website that is accessible to everyone. A static website is easy to deploy and is shareable via a single URL.