Hello! My name is Constantine, and I am a Head of design at IMAGA. This article is about design systems. As always, I tried to make the article as simple and engaging as possible.
So, let's talk about design systems because I regularly have to either discuss them or clarify what exactly the person I am talking to means when they say «we need to create a design system».
Explaining design system using cats and Lego as examples
Imagine your child was given a task — they have to make ten models of cats.
There are several things you could do. For example, you can use Play Dough, clay, or paper and make ten unique cats.
Yet another option is to use Lego to build models and make them either completely similar or only slightly different. But either way, they will be square or rectangular, with bumps.
There is a factory in China that makes millions of standard little bricks, gears, and motors. Excellent logistics makes sure everything is delivered to the stores. Clear instructions help you assemble spaceships and kittens. All this is a design system. Lego cats are cats made thanks to it.
Here's the good news: in digital, you can relatively easily create your own cube factory and start assembling cats of your liking. You don't have to spend a fortune on Lego, you have an infinite number of bricks’ copies because they are digital!
But you also face the same restrictions: you can only make the type of cats that your factory will allow you to make. You have to set up all the business processes, write instructions, etc.
Why we need to talk about this: the Gartner hype cycle and the Plateau of Productivity
I like how the Gartner Hype Cycle describes the life cycle of probably any technology.
Several years ago, the community was wildly enthusiastic. Everyone claimed to be «the first company to introduce a DS,» and «the first agency to make a site based on a DS.» But few seemed to realize what they were getting themselves into. Sometimes I even thought that it was more of a PR tool rather than a way to reduce development costs.
It seems that last year, design systems finally overcame the Hollow of Disappointments and are now somewhere on the Slope of Enlightenment, striving to reach the Plateau of Productivity.
Now finally, the DS is being looked at as an investment in the product itself, a way to reduce costs and increase the speed of product development. It has become a usual working tool of a product team, not a hype toy for enthusiasts. Any decent (and indecent) manager and designer needs to know about this tool.
What is a design system in terms of production
This is probably the most important sentence of this article:
A design system is a UI kit turned into code and linked to it, i.e., it is a [UI kit] [+] a [code] system..
The main idea is that a UI kit ≠ a design system!
Let me elaborate on what I mean.
As you know, a UI kit is an ordered set including all the elements of your digital product: buttons, forms, typography, etc.
Usually when they say «we need to make a UI kit,» they mean «the designer needs to gather all the elements in Figma (Sketch...) in one place, show all the states, and add descriptions, so everything is clear and you can develop quickly and efficiently.»
Less often the same is said about front-end developers, meaning that you have to HTML all the elements so that you could reuse them.
Or, in other words, the pictures should be turned into code and preferably put in a special repository.
But now, if you decide, for example, to change the basic red color to pink in the design, first you have to use design programs and then correct the code, i.e. synchronize the UI kit and code.
This is where you can turn it all into a system. For example, you could write rules for transferring changes from Figma to the layout and then to the site. Or you could do more. Just as systematically you can automate the synchronization of changes.
Imagine that you have updated the logo in a design program. Click-click, and it's already on the site and in the app at the App Store...
It isn’t important how to do it, automatically with a script or manually by an approved business process. What is important is that your design process is systematic, meaning you have a design system.
(Although, of course, to do this manually in 2022 is a ridiculous idea.)
Onward to a brighter future!
Cheers! Let's synchronize, systematize, and automate everything!
Unfortunately, this is still just a dream, but we already know how to do some things. Now I will tell you about it as simply as possible.
First, the most popular (and perhaps the only reasonable) approach to building a design system is called «atomic.» It's simple, a page consists of blocks (organisms), blocks consist of shapes and buttons (molecules), and shapes and buttons consist of lines, font, and color (atoms).
Design tokens can store basic values (atoms) such as color, button rounding radius, font parameters, etc. These values are associated with the repository. This way, if you change the value of a token, for example in Figma, it goes into the repository and then can already be automatically synchronized with the site.
Repositories like Storybook, Git, NPM, etc. help developers organize code storage and help with code integration into various frameworks.
A framework is a software platform that makes it easy to work with the structure of a digital product and helps to do high-quality development. I think you've heard something about React, Angular, Vue. This is it.
Fighting a losing battle with synchronization
Unfortunately, not everything can be integrated simply and cheaply. For some things, we have no way of doing it.
For example, even now, in 2022, it is difficult to synchronize components for mobile development. Many web integrations are easier to do by hand than to automate. Parametric component variations are also quite tricky.
For example, there is a button design. Technically, you understand how you can automatically generate it for the web, for iOS and Android apps, as well as for b2b and b2c sites. Reduce here, convert to rem there, and stretch. So, it looks like they created an algorithm and — magic! — everything is done... But in reality, there will be a custom development, which would require specialist support, and there is no designer-friendly WYSIWYG interface.
It's easier to have four different design systems with all the stuffing: tokens, repositories, and people for synchronization not only within a DS but also between them.
Overall, though, everything is moving toward a bright future where we can change one template in Figma and it will automatically and seamlessly apply to a functioning site and app in the App Store. In the meantime, we are climbing the Slope of Enlightenment.
One more fly in the ointment
I really like design systems, but they have some pretty significant flaws and specific features:
- Implementing a design system is difficult and expensive, especially at the initial stage. You need experts (and there are few of them yet), resources to make up components and templates, the patience to put it all into your product, and the willpower to keep it systematic. Large projects sometimes even have a whole team of design system keepers. (Although I've heard of an approach where this function is distributed among the entire team, even in large IT companies.)
- Having successfully implemented a DS, you may find out later that your product has lost flexibility, and the pages of the site look like panel buildings. Moreover, it’s hard if not impossible to make a new unique feature, by the time you implement, test, and integrate a new component in the DS, it seems you don't need it anymore.
- It's not always cheaper. Yes, design costs are going down. But there is work to maintain and develop the DS. That is, the costs are simply passed on to another unit. Then add the cost of building the infrastructure and maintaining it...
- If you decide to change something drastically, such as the navigation structure, or a completely new brand book — there is a risk that it will be easier to throw everything out and start all over again. It's like if you decided to switch from plastic Lego to metal bolts. We throw everything away and build a new plant.
It’s all well and fine
Still, the DS has big advantages that can boost your project and do a lot of good.
- Using a DS, product scientists and project managers can build simple screens and introduce new features themselves. The speed of delivery of new functionality and experimentation increases dramatically as the design and layout phase is thrown out. There's no «oh, that's how the designer sees it, and the front-end developer has paws.» Front-end developers themselves don't spend time on the boring table layout, but on integrating a calculator, for example. This requires using your head and creativity, and professionals tend to enjoy it.
- Design costs are reduced: if a DS has enough budget, then everything comes down to improving and enriching the current components. Minor design changes like adjusting colors, changing the logo, or the shape of buttons are done almost instantly. «Do you need a new product page? Let's take these five blocks, change the text and images, and add a link to the form — here we go, everything is ready!»
- The product looks consistent. Both the minor page with legal documents and the super conversion calculator look and work in the same way. No one can accidentally ruin it. Yes, panel buildings can look beautiful!
To summarize, you need design systems if:
- You have a long-term project that you are ready to develop systematically.
- You want to experiment a lot, make steady improvements, and systematically develop the product.
- You have several teams working on one product and they need to maintain consistency.
- You just love plants and kitties.