How to build design systems that everyone will love

Design systems are very popular these days. They are really great, but the definition and understanding of a "design system" term became a bit vague. What is a design system? Is it a components library? Why do we need a design language? Who owns it - designers or developers? How to test it? How to "sell" it to a manager? And a lot of similar questions which made harder to understand how to build a good design system.

I will try to answer on all these questions and share my experience how to build design systems that everyone will love.

I've worked on design systems for different companies for last years and I've faced a lot of different challenges so I believe that my experience would be helpful and this article won't be just another article about design systems.

What is a design system?

The traditional design industry is already very mature and rich. The web design industry is still young, but we can find a lot of inspiration in the traditional design. Design system is a good example - you can think about it as a brand book.

What problems does design system solve? Why do we need it? The main reason - to have a consistency in the design and in the user experience.

Design system is not a new thing in dev world, we had something similar for a long time already. UI kit, styleguide, components library - but they were mostly focused only on technical implementation.

We need something more than just components library. We need consistent design foundations across the whole company. We need a good human-readable documentation that non-tech people will understand.

Design system is a product. It's not about technical implementation only. It's a single source of truth of our design process. It's a system which defines the design vision and rules (tokens, typography, components, etc.), helps to keep the UX consistency and creates the power of the brand.

What does the design system contain?

In general, it has the following parts:

• design language
• technical implementation
• documentation
• testing
• communication

Design language

It's a system of meanings as a way to communicate with users. It's a set of rules and guidelines how our products communicate with users. Treat it like a brand book.

It's not just a set of colors that we use, but set of rules and patterns, how exactly we use colors, fonts, verbal language, any styles, what are our patterns. It helps to answer on questions like: "what does italic font style mean?", "why does this button have no background color?" and so on. And the answer should be easy to understand, like: "a button without border and background means that's a dismiss/cancel button which should not be the first thing that users see".

It should be defined and aligned with both design and frontend side, it would be extremely beneficial to work together from the very beginning.

Technical implementation

It's a technical implementation of design language by converting it into design primitives. Fonts, color palette, styles for spacing, border-radius, theming. Building reusable components.

There are different ways what project structure to use - just one repository with all components, or mono-repo with each component as a separate package. It's really up to you and your colleagues, discuss it and figure it out what works best for you.

Try to be sure that you are not adding anything new as a new component, keep an eye on the size of a library, if it's becoming too big - maybe it's a time to reconsider some of your components. Maybe, clean it up or merge some of them.

Some people say that it should be framework agnostic, but again, it's up to you. If you use React everywhere - build components usingReact. If you have different platforms - build it using what fits you best.

Documentation

My opinion that is an incredibly important part. I've seen nice design systems with poor documentation and it's a solid reason why a design system can fail. It's very easy to treat this documentation as technical information for developers only, but it's not. It should be written in the way that everyone in the company should understand how design principles work there.

Yes, tools like storybook help a lot, it helps to create beautiful documentation pages very easily, there is a lot of great add-ons and plugins. And it's really great, but we need to add more value to the documentation.

I'm not saying that you should stop using Storybook, no, it's an amazing tool. We definitely need to write tech specs (like what properties do components have, what types, etc.). We just need to add more broad information about our components in a human-readable not technical language, when exactly we can use, for example, tooltip, when we should not use it (and what to use instead of it), how does it work together with other components and so on.

Categories, more general information about the design and our principles, pages about typography, colors, fonts, etc - they are all crucial parts of documentation. Use cases, some guidelines save a lot of time. Not even only developers and designers time but also product people' time, QA people time because they will understand how things work.

Documentation should be always up-to-dated. If someone makes changes in the design system - it should be reflected in the docs.

Don't limit yourself by storybook, you can build custom documentation website to make it more custom for you. A lot of companies do it in that way.

Few good examples that I personally really love:

• Skyscanner design system docs - https://backpack.github.io/
• Shopify design system has a very well-written documentation - https://polaris.shopify.com/

Testing

To make a design system even better we want to have well-established processes of testing our design system.

Testing components could be tricky because we need to check both technical and visual sides. And if technical side could be covered quite easy by unit tests, the visual part is not so simple. We want to be sure that everything is fine before we release without a lot of manual work (let's say - checking our changes somewhere in test/staging environment).

There are great tools to make automate this process, for example:

• https://www.chromaticqa.com/
• https://percy.io/

with CI/CD integrations, dashboards, etc. It saves a lot of developers and designers time.

Communication

Besides all those parts, internal communication between everyone involved into design system is critically important. Doesn't matter - do you have a separate design system team or not, how big is your company. It's always should be a defined communication way. It can be status update meeting, bi-weekly design/developers knowledge sharing meeting, small talks during company tech talks, slack channels (like with releases updates, another one for questions), etc. Be sure that everyone is informed about all updates.

Wrapping up

Of course, it's impossible to do all these things right from the beginning. Start small and keep the global picture in the mind. Every company has its own processes and problems, so you will figure out the right pace and approach by your own. Maybe you will find another great tool that suit you more, or your definition of a design system would be a bit different. Remember that it should be a single source of truth of your design principles.

Do we really need a design system?

I strongly believe that everyone should start with this question when they start working on a design system. I

For small companies it probably won't be the right moment to spend time building design system. Companies have less resources but a lot of features to build. They can care a bit less about the design consistency for a while and it's absolutely fine.

However, when companies grow and especially when they grow fast, it's very easy to lose that design consistency. The company starts to hire more people, open new offices, launch apps on different platforms. When some of these situations happen - this is a moment to think about the design system and start to build it.

Perhaps, developers already have a components library and that is a great base for a design system. Don't stop here because it can lead to new problems:

• A collaboration between designers and developers becomes less efficient. Developers stop paying enough attention, they could start creating new buttons or icons by themselves when they see something new in the mockups. I've seen situations when developers were adding more and more modifications on top of already existing features instead of aligning it with designers first.
• A new component could be stored in the specific app's structure, not in a design system because "hey, it was easier, we needed it asap and anyway it's specific to our app".
• Different platforms have a different user experience, but users want to have the same feeling when they switch, for example, from mobile to desktop.
• Designers work more like design agency, they just build mockups. Their core values are not the same as developers have. Both sides use different design language, different color palette, different tools and no one knows what exactly they use.
• It becomes difficult to test changes. We update one button, but we want to be sure that this change doesn't break anything across all our applications and all pages.
• Documentation is mostly focused on developers. Non-technical people have to spend a lot of time to understand the difference between primary and secondary button and when they can use the first one and when the other one.
• No one is really maintains and owns that library, it's just some shared library without any plans. Developers could start using it less, not improving it, using it as a package where they can get the buttons and colors from.

How to start building a design system?

Once I was on a frontend conference and after one talk about particular tool for design systems (how to use css-in-js in the best way) I had a small talk with another visitor. He had huge expectations about this talk because he had so many questions. He was a bit frustrated because he had one general question to be answered which wasn't answered during the conference talk:

— Ok, that's all cool, but my manager doesn't want us to spend time to build a design system because it doesn't add business value - what should I do?

This is a very common situation and you can try the following:

• be sure that you really need a design system. Not only because it's a hyped topic nowadays.
• discuss it with designers and frontend developers first, you need to be on the same page. Find common problems, prepare some examples with data and numbers. Something like "we spent much more time on that new modal window task because all our modal windows were different" or "fixing this visual bug took more time because we had to check all pages and different user scenarios". Without proofs, it can be difficult to convince your manager.
• you should really push this idea and believe in it. Spread this idea across people, especially along product owners, stakeholders, discuss it with your manager during yours 1:1. Start discussion on Slack, organize some workshops, make lightning talks, show examples from competitors - do your best to get people involved into design systems.
• spend some extra time to build a proof of concept. If you have local hackathons - this is a good moment to work on it and present it. Or try to build it piece by piece when you work on your daily tasks - after a while it can be already in a good shape to be a foundation for a design system.
• people like numbers so be specific when you present it to the business side. Remember that they probably not technical people, so make cases based on examples, how much time you could save, how would it change processes in the company, the impact on the brand. Try to sell the idea.

How to make people love it?

• have a separate task board - it helps to keep all issues and new tasks. Everyone can see the current progress and future plans. Otherwise, a lot of issues or new features could be forgotten. Sometimes you can add a quick fix in your code (like a new color) and you promise that you'll add it to the design system later. But every often it never happens. One more benefit of this approach - tasks board makes people care a bit more about the design system.
• it takes a lot of time and effort - it's not just a few meetings between developers and designers and a few weeks of development. Defining design language requires a lot of communication with different departments - you need to understand what marketing needs, what sales want and all other teams. We should collect all the data from different areas to make our design language strong and meaningful because we build a foundation that defines our design vision. Be ready to make changes, to redefine some parts, be flexible. As any product development you would face challenges so just be open for them.
• everyone should be able to contribute - it doesn't really matter do you have a separate team for design team or not. No one should think that he cannot change anything in the code base because "it's not my project". Otherwise people will have less motivation to use the design system because they will think that they cannot make any impact and everything is dictated by someone.
• write human-readable documentation - keep in mind that you write it to people who can have no technical knowledge or no understanding how the interfaces work. If you describe how, for example, grid system work - make it clear, give explanations why grid system is needed, why do you have 12-columns system, how does it affect mobile version and so on.
• keep documentation and task board up-to-dated - it's important to stay on the track. But it also helps a lot for new joiners to understand how everything works here.
• have knowledge-sharing meetings - I found these meetings with designers and frontend developers extremely helpful. Share what designers work on, what frontend developers do, what tools do they use, share nice examples from other companies, how you can automate some parts, etc. Find a format that suits you more, but keep this two-ways communication.
• be patient - don't expect that everyone will love and use design system immediately. Patience and teaching are important here. Sometimes you can meet resistance from teams (they could be very busy or not ready for changes) and it's fine. Most of the people like stability and bringing a design system will distract this stable and predictable environment. Just be patient and try to show best pieces of a design system and one day you will see how more and more people would use it.
• give your design system a name - after all, it's a product and it should be treated as a product. The name gives it a real power to it, it won't be just another design system or shared components library.

Don't forget that, in the end of the day, we work with people and our products are focused on people. And a design system should be a product for everyone, created with love.

—

I hope my article could help everyone who is building design system. Feel free to comment, ask me anything and share your experience as well.