If you ask Kaari Saarinen, the design systems lead at AirBnB, for a definition of a design system, he’ll tell you it’s a “shared, integrated set of patterns and principles that define the overall design of a product.” Since AirBnB basically invented design systems, I’m not here to tell him he’s wrong, because he isn’t. But working in the trenches of design every day, what does that shared set of patterns and principles look like for those using it? How does it end up affecting the way designers and developers do their work? This concept can be hard to wrap your brain around, especially if UI/UX design and development isn’t the world you live in. Here’s the most simple, practical explanation of a design system I can give you, plus the best argument for why you might need one—and how to get started.
How Does a Design System Work?
My workaday definition of a design system is a library of pre-existing components that makes it easier and faster for a brand to update or maintain their proprietary software and apps. But before this library can exist, your first tactical step is to create what basically amounts to a card catalogue—a written list of the different components you want to include in the design system. Just like you can’t check out books if the library doesn’t know what they have, you can’t build a design system without first knowing what it will include.
So, what goes on the list? Design systems are made up of four levels of components. You might have created some of these already. If not, you can also start from scratch:
- Atoms are the most basic level of design, like your app’s buttons or a single field in a form. These each have their own unique properties, like atoms in chemistry.
- Molecules are combinations of atoms. Science! When you put together a button and a field to create a search form for your website, you’ve made a molecule.
- Organisms are combinations of molecules. If you use the search form, a site navigation menu, and a logo to create a website header, you have built an organism.
- Templates are created when organisms are combined to show how the software will be laid out and put each piece in context.
Before you decide to add everything and anything to your design system, it’s important to know that the average design system includes less than twenty of these pieces total. According to a 2018 survey by Sparkbox, the most successful design systems contained 14 elements, while less-successful ones contained 11. This distinction reveals how much difference it can make to have a few extra pieces agreed-on from the beginning.
How is a Design System Implemented and Maintained?
To start building a design system, the process seems deceptively simple. A designer creates concepts for the atoms, molecules, and organisms on the list that still need to be built using a tool like Sketch. After approval, they deliver these designs to the developer, who codes everything they have been provided exactly as it has been sent. For this part of the process, we at Crafted like to use a tool like Zero Height where the developers can see the design even while they are working on the code. Once everything is built, both the code and the concept are stored in the design system, to be used by every future designer and developer moving forward. Sounds simple…right?
Actually, a design system requires a significant investment of time and energy from designers and developers, especially when many of the components still need to be created. Even when they already exist, agreeing on one color/shape/size among the many that have been used can be a struggle. The industry is full of horror stories of people trying to implement a design system without a plan and getting so far into the weeds the project totally fails. Two main points can prevent this happening to you:
- From the beginning, it’s essential that everyone on the team agree to the list of components, the “card catalogue” for your future library. Pro tip: resist every urge you will have to add things to that list in the future. As you go, you will want to add things as you see the design system take shape and want it to do more for your efficiency. But it’s extremely difficult to take components back out, and the more you add, the more future customization will be limited. (You’re also just pushing out the day where you can be done with the design system and get back to the project itself.)
- The flip side of this coin is, don’t put off tasks while you are creating your design system. It’s easy to say you will create certain atoms later or decide to apply revisions to something in progress after you finish a new piece. But this is the way things fall through the cracks, and one pathway to a design system full of inconsistent materials.
In short, designers, developers, and other stakeholders need to agree on a strategy to tackle the design system implementation and stick to it, even when it would be easier or faster to take a shortcut. After all, consistency and shared strategy is the whole point of a design system!
When is a Design System Needed?
Like every innovation, some people will claim that a design system is a silver bullet and will knock out every single one of the lengthy approval timelines that can make development projects so challenging. This is true to some extent, but not for every digital product. A marketing or brochure website running through WordPress doesn’t really need a design system, because the lifecycle of design and development for those products isn’t long to begin with, and they always exist within some pre-existing template or another.
Design systems in a legacy project can also do more harm than good. When upgrading a legacy system, there is a lot of custom work that needs to be done page-by-page. Design systems are most useful when they support designers and developers in moving the product forward faster. They should not be a way to hold everyone captive to what has been decided in the past when critical thinking shows a different approach would be better. For instance, if you force every form in a legacy system to look the same with the same number of fields, it can lead to a lot of chaos. Instead, a design system is a shared foundation to keep a product steady and consistent as it grows to success.
It’s Still Confusing…
Like I said, I know it can be hard to visualize, so I’ll explain the appropriate use case for a design system using the example of a two-sided project we did at Crafted. We supported a national brand in redesigning a digital product that had a consumer-facing side as well as an administrative back-end side. The administrative back-end was a legacy system and upgrading it was a time-consuming process with long approval cycles. By comparison, when designing and developing the front-end, we implemented a design system that let us take pages from sketch to MVP in a single morning, and then see them approved in the same day.
One might sound better than the other, but both approaches were what was needed for that product to come out great beginning to end. The design system empowered us to use critical thinking to make big decisions easily on the front end, while we applied custom expertise and did fine-tuning on the back end. If we went back in time, we would do everything the exact same.
tl;dr: Sometimes a design system is invaluable, and other times creating it is more effort than it’s worth.
If you need help creating a design system, or even deciding if a design system is what you need, Crafted’s team is happy to talk through the details and share our expert opinion.