How design systems are created: sharing our own example. Part 1

Hello everyone. My name is Dmitry Pashkevich, and I am a frontend developer at Quadcode, specializing in the creation and development of design systems. This article is intended for specialists at various levels who are involved in design systems: from consumers and component developers to team/tech leads building design systems from scratch. Here, I will share my experience, and the path I have taken from creating UI-kits to fully building design systems, and show the benefits that a ready-made design system has brought us. If you are looking to deepen your understanding of design systems, then this article is for you. Have a nice reading!

Intro

To some extent, this combination of words has become a collective term because experience shows that different companies have different interpretations of it. Understanding depends on the maturity level of the team/project/company/processes, the presence of desire, time, and resources, and most importantly, people with “passionate” eyes who will develop this direction despite all the difficulties.

I have gone through the path of creating various UI kits, transforming these UI kits into design systems, to fully building design systems from scratch from the perspective of FE development in the following roles:

1. Consumer of components.
2. Developer of components.
3. Lead in building a design system from scratch. Here, 80–90% of the time was spent on component development, while the remaining 10–20% involved applying components in the product code, as well as sharing knowledge and interacting with the FE development team.
4. Product developer — when you “build components” and immediately implement them during product development. In this case, the entire team participates in working on the design system.

In this article, I want to share the experience we have gained and try to structure it using our company as an example. I will demonstrate the phases of formation and development of the design system that we went through, share the technical stack of our product, and provide insights into the benefits the ready-made design system has brought us.

On one hand, I would like to immediately provide a definition of what a design system is in my understanding, but let’s approach it slightly differently and formulate what comes after the main part.

<SPOILER> For those who are eager to learn the differences between a design system and a UI kit, you can skip ahead to the second part of my article and scroll straight to the section“What is a design system, in summary.” However, I still recommend reading from beginning to end. </SPOILER>

The problems that lead to the emergence of design systems

Firstly, I will start with what usually initiates the birth of a design system. Most often, the reason lies in accumulated and recognized problems that the whole team or specific parts of it begin to address — the areas where the pain is the greatest.

So, what can these problems be?

1. The old design is lost. It is no longer supported, or it exists only in images (yes, it happens). In this case, developers themselves or with the help of a designer come up with ways to incorporate specific elements. The consequence is that the development of new pages becomes a pain. The product inevitably becomes inconsistent across different pages because the logic of interface construction is lost.
2. The old design/interface has become morally outdated, and a redesign is necessary. The question arises: what should be done? Should the current product be modified: modularly, page by page, or should it be built from scratch, etc. — each person chooses their own path. Different paths have nuances that need to be dealt with.
3. Communications regarding feature creation/interface changes exceed reasonable limits. In this case, creating a new element or UX approach becomes disconnected from the product. I think this can be considered as an extension of point 2 and the team’s desire to provide users with a more convenient and modern product.
4. Creating any new feature (even a similar one) takes a lot of time. Various factors can contribute to this, such as poor architecture inherited from the MVP project, outdated tools, or the inability to simply update.
5. The necessity to improve processes. The desire to create a unified point of communication within the team, at least between development and design. A little spoiler: as practice shows, during development, this point, also known as the design system, becomes at least a single source of truth, and discussions constantly arise there.
6. The presence of significant routine work when creating new layouts or coding within a single product. Sometimes, there is no opportunity to reuse a UI kit in design or code. This situation often arises across different projects and occasionally within a single project (more relevant to design in a specific tool). It looks something like this: you open a new design layout, see similar elements but with different names. It becomes difficult for a developer to match elements with the code, and there is a need to standardize everything to avoid wasting time on unnecessary clarification when it’s simply a matter of taking, implementing, and using.
7. There is a product pool within the company, and at some point, there is a need to standardize the UI/UX. Each product has its own team of designers and developers. Does each team need to develop its own UI kit? It happens sometimes. Then the implementation of a design system can start from the design side, which brings everything to a unified appearance. As a result, multiple UI kits may appear in the code due to resistance in different teams, but after a couple of iterations, a unified component base begins to emerge.

These described problems are not listed in any specific order or importance; any of them can be a starting point for creating a design system.

Phases of forming a design system

After realizing some of the above, the process usually begins to create something similar to a UI kit or a large-scale design system. It unfolds as follows:

1. Human and time resources are allocated.
2. Requirements are formed for a technology stack that will meet modern challenges.
3. Based on the requirements, a stack is chosen. The first demo versions of project skeletons appear.
4. Initial agreements between development and design teams emerge — the search for a common language, the desire to synchronize.
5. The core of the design system is born, or it’s more accurate to say, the UI kit, as the processes are yet to be fully formed.
6. The first components are created.
7. The components are tested in the first product feature, and adjustments are made to them.
8. Organic development of components in design and code occurs, with or without design reviews.
9. There is more time for reflection on what has been done and what currently needs adjustment. The development and design teams align their approaches and toolsets to help move forward, including:

• Identifying and resolving issues.
• Introducing new processes (syncs — meetings on how designers create a design, frontend developers work on frontend, QA tests the frontend part of the application, and how everyone interacts with design layouts.
• Implementing new tools.

10. Gradually, there comes a phase where the design system team or individuals responsible for the design system focus less on creating new components and more on assembling pages and maintaining the components.

In this stage of my personal experience related to design system development, I consider this an ideal path to follow. However, there are always nuances, and it depends on the situation.

Phases of design system development

If we delve deeper into this list, the following phases of development can be identified:

Hot phase: This is when components undergo the maximum number of changes in design/code during their implementation into the final product. This phase can last from a few months (on average, 6) to several years. The minimum duration I have experienced is 3 months, and the maximum is 1.5 years. It depends on the initial agreements, the experience within the development team and the business that allocates resources, time, and sets priorities.

The development of components in both code and design occurs simultaneously. There is a connection between development and design, establishing a common language, component naming conventions, and determining the best way to organize the library. Efforts are made to ensure that everything in the design references basic components or that more complex components are built from basic ones.

Many growth points are identified but may not be addressed due to resource limitations or a lack of critical necessity at this stage. These issues are addressed when time becomes available or when it becomes difficult to move forward without resolving them.

The improvement of design system workflows for design and frontend development occurs in parallel. They improve their own processes, and gradually, they start to solve their respective issues.

Sync phase: Shared sync meetings are introduced, such as weekly or sprint meetings, where design and development discuss problems, questions, and suggestions, and agree on small steps to improve their collaboration.

Sometimes, the sync phase can reach a deadlock, where the team starts getting stuck in their own perspectives and needs to share their problems with a third party who is not as deeply immersed in the context. This person can help find solutions more quickly.

Deficiencies in processes related to design review, such as how it is conducted from the design side, what and how they review, are addressed. Critical design changes and priorities are determined. Misalignment between design layouts and compressed release timelines are addressed. Understanding how design processes translate into components in Figma, or vice versa when a design doesn’t know how components are transformed into code, is also resolved.

Plateau phase: Creation of new pages/features/adjustments does not require major rework of key design system components or only involves minimal changes. Major changes in component behavior are possible. For example, rethinking UI/UX when something is found to be inconvenient and needs to be redesigned or when new components with different behaviors need to be introduced. New components are occasionally created.

During the redesign of our product, we went through all these stages of realization and acceptance at a relatively fast pace: we built a working product, not just components, within six months.

I’ll note that all three phases can repeat from time to time depending on the required changes. For example, when separating components into a separate library, adding theme management, establishing stricter component creation standards, or implementing them in a new project.

In the second part of this monumental article, I tell about how to define product requirements and, as a result, design system requirements and also explain why’ve chosen Mantine as a foundation for our own design system. Subscribe and stay tuned! I would be glad to answer any questions in the comments.