UX/UI DESIGN

Our experience in implementing a design system. Part 1

How We Came to Need a Design System for Internal Company Products

1. Introduction
2. How Did the Idea of the Design System Come About?
3. Approval Process and Organization of Work
4. Tokens Naming System

Introduction

Hi, my name is Iryna, and I’m UI/UX Designer of internal products in G5 Games. Nowadays, it seems like only the laziest person in the world is not talking about design systems and I thought — well, why shouldn’t we be part of that conversation too? Moreover, I believe the most valuable insights come from each team’s unique experiences. I will try to explain ours.

From the start, I want to warn you that this will be purely about our experience, the difficulties we encountered in the process, and our results. I do not see the point in going into theory about what a design system is and what it’s for, how tokens work, etc. Half of the Internet has already written about it.

So, we have several internal products such as an HR portal for all employees, a specialized system for our recruiters, an interface for managing company surveys, etc. Different teams, including various designers, have worked on these products at different times and are still working. And since there were no established general rules, UI Kits, and especially a design system, everyone created the product at their own discretion.

As a result, not only did the products look completely different to users, but they also demanded more design and development time than necessary. I encountered this issue when I started working for the company. For example, I had to spend a lot of effort to understand, in which case Gray 1 should be used, in which Gray 2, and on what principle 13 and 14 font sizes work in the interface.

How did the idea of the design system come about?

Some time ago, the question of creating a general design system was lingering in the air. We found ourselves managing five internal products with the collaboration of three UI/UX designers and three development teams. We started with a small review to see how huge and fundamental the differences between the products were, and whether we were dreaming big. Surprisingly, it wasn’t as bad as it seemed at first glance. As an example, a majority of the interfaces shared a common font family that could easily be incorporated into other products. The color palette predominantly consisted of varying shades of blue. We made the decision that, over time, we could standardize the majority of the components and the approach to their creation and utilization. For example, rather than having four different buttons, we would create one button to be used across all products, incorporating the same color, font tokens, space, shape, etc. It would be used only for new facility creation.

Still, there was the development issue and varying specialist approaches, but we’ll return to this topic later. In the end, an optimistic and exhilarating decision was made: the decision to create a design system! In parallel, our colleagues started working on creating the same system for client products, but they decided to start small and test it only on one project.

Approval process and organization of work

The next step was that our Design Director, as part of the company educational meetings, organized a large presentation for all employees. The purpose was to introduce the concept of the design system to all employees, outlining its significance, and the advantages it offers, providing a basic understanding of the subject while also answering the questions.

After that, we decided to schedule individual meetings with each team (mostly product managers and developers) and tell them in more detail what we plan to do, and the value it would bring, and explain the expectations and requirements from them. It’s worth saying that it was very important for us to get the agreement of our colleagues. Because by design system we meant not just a general UI Kit and kind of guidelines (as some people sometimes mean when they talk about a design system), but a complete, connected-to-the-code system which means tokens that can be effectively managed in the future. In discussions with product managers, we reached a consensus not to make any global changes in the interface during the initial months (in order to avoid surprising customers and users) and we would devote time to work not to disrupt the main projects. For example, we have determined that we would not radically change the typography. Most of our products already utilize the same font family. Our approach is focused on reducing the range of sizes and styles to the essential minimum. After all, the transition from font size 13 to 14, or from Medium to Semibold, is often unnoticeable to the majority of users. The same principle applies to the color palette, etc. But further details on this matter will be covered in the next parts of the series. With the developers it was a little harder: a lot of questions from the category of “Why do we need it, if in our code everything already works fine? How will all the teams implement one thing, if we do not know how other development teams work? Their approach can be very different from ours, and we do not really want to agree and change something”. Of course, I am simplifying things a bit, but that’s the point. In the end, we tried to explain that this will eventually simplify and speed up their work processes too; that there will be consistency in code and design, subsequently reducing errors and the need for bug fixes; that it will be much easier to read the design, develop new features and make changes. And since some developers are involved in several products, they will be able to use ready-made solutions in other projects. Of course, everyone was worried about the amount of work that we would throw on them. We explained that we would proceed gradually, starting with something simple, and we would come and show what we could do at each stage. Specifically, what were the tokens named, and how many of them were created (more for development). We explained how the interface would look after the innovations for product managers, etc. Encouraged, we exhaled happily and ran towards the sunset design system. Naively, we didn’t know yet what awaited us when we came to our colleagues with real tasks.

Tokens naming system

Next, I would like to discuss the token naming system we chose because it is one of the fundamental aspects of any design system. It determines how you create tokens, how you apply them, how flexibly you can use and manage them, and how easily and quickly newcomers can integrate into your system.

Our colleagues, who were concurrently working on the client design system, discovered an excellent article titled Naming Tokens in Design Systems. Within this, the author explores various methods for naming tokens, deals with the templates and levels in naming, and finally proposes his own variant. After thoroughly studying the system presented by the author, we concluded that this approach is closely related to our own, and it ensures consistency with the system for client products. At first glance the system seems quite complicated, that wasn’t like we once read the article and easily began to use this naming immediately. But when you start going deeper into details while working on tokens, the convenience of this approach becomes obvious. You can create as flexible tokens as you want. For example, you can decide, whether you want to use a token for one main button or for all actions in your product. Most notably, from the token’s name, you can find out all the necessary information about it. Therefore, the token int-input-font-placeholder clearly indicates its purpose — to be employed for all placeholder fonts in inputs. It’s difficult to make a mistake, isn’t it? So every level represents the definite value of the object and shows how to use it exactly. It also helps developers understand the logic of using tokens in the interface, leading to increased speed and efficiency in their work.

In short, you have 4 groups:

• Namespace
• Object
• Base
• Modifier

which contain 13 subgroups from general to specific that you can use, depending on how detailed your token should be.

While the article provided certain examples, they proved insufficient for our needs, and certain realizations only dawned on us at specific phases of our work. For instance, we initially didn’t fully grasp that an element must link to the component mentioned before it. For example, an icon can function as a standalone component, or it can serve as an element linked to an input. And you should use it as an element if you want to create, let’s say, a color token specifically for this icon in the input.

Furthermore, we didn’t immediately understand the full extent of possibilities within the concept or its scope. Also, at some point, we encountered the fact that we need two variants and there is no other way to name the token. While revisiting the article, we noticed the use of the prefix ‘sub’ in a particular context, so we decided that this was good enough and allowed ourselves to use two variants in one token.

In any case, any approach must work for you, not against you, so no one forbids changing the rules a bit in the process. The main thing for the system is to remain manageable and understandable. In the next articles, I will go into detail about the nuances we faced and the decisions in token naming we made.

In the end, we ended up with a sheet that we use as a constructor when creating tokens. We have it in common with the client’s design system and, of course, it will continue to expand as we go along.

So why did we basically decide to do this instead of adopting another method used by many open design systems, like creating five shades of gray and naming them as Gray-100, Gray-200, and so forth, for flexible use?

In general, it’s obvious because our goals are completely different. While an open design system can be used by anyone, and styles in various products can be used in completely different ways, we exclusively create ours for internal use, negating the need for unconditional flexibility. That’s why it was important to find the right balance between the flexibility of tokens usage and manageability. The aim is clarity — an understanding of which gray I should use for this icon. But at the same time, it is completely unnecessary to create separate tokens for different icons in buttons, inputs, menus, etc. We don’t create a product from scratch, and we know in advance how we are going to use a particular token. It can be assumed how flexible we are going to manage it in the future. It was also important to be clear about which token could be used for which item. First, so that it would be easier to work with and not waste time remembering, and second, to make the process of entering the design system as understandable as possible for newbies, so that they could use it even without help, rather than, as I wrote above, guessing what shade of color or font size to use.

In the next part of this series, I will delve further into how we combined the styles of different projects, and I will start with the fonts.

Author of the text: Iryna Akhramovich, UI/UX Designer
Author of the images: Svyatoslav Kovtun, UI/UX Designer