Sound company experience
I’ve been working on a design system for a year and a half now, so I know every little detail here. And in this article I want to tell you why we need a design system and in what form it exists in our project. And also what has changed in the application architecture and code after its implementation.
Spoiler – as a result, the development of features became 2 times faster, the assembly of design layouts was 3-4 times faster, and the application UI was freed from the chaos of random fonts and icons and unified. Read more in the article.
Why did we need a design system?
Every time the idea arises to introduce a new feature or refactor, it is important to understand exactly why we need it. Let's start with this.
The main goal of a design system is to speed up the UI development process. To do this, we first need to simplify the processes of creating layouts for designers, and then facilitate and standardize the processes of translating these layouts into code.
Our project has been in development for almost 7 years. During this time, we have accumulated a huge number of color solutions and icons. To create a layout for a new feature, designers often had to make copies of ready-made interfaces and make changes to them. For example, to add new colors. And when implementing these layouts, developers needed to duplicate existing pieces of code due to design differences. This increased the code base and added QA work.
This took a lot of time from designers, development, and QA. Often the layouts may differ quite slightly from each other. But there are more and more such changes over time. And as a result, it may turn out that the designer simply does not know what reference to take for a new layout, because there are many very similar sources. To prevent this from happening, we need a design system.
When we first started out, there were three major design issues with the Sound app.
Problem 1: UI is not unified
It seems that the interface is made in the same style, but in fact there are a lot of inconsistencies: different color schemes, there is no common style of icons, the appearance of tracks in similar sections of the application differs.
If you go to other screens of the application, the problems become more and more noticeable. This greatly degrades the user experience – you have to learn new ways to interact with the UI on different screens.
To prevent this from happening, all elements need to be unified—to create a system in which the rules for developing a user interface will be clear to designers, developers, and QA.
Problem 2: Colors and fonts
Before implementing the design system, our application had 176 different colors. It's a lot, yes. Some were scattered throughout the code of the entire application and because of this they were often duplicated – during development it was not always possible to find and understand that the color already existed.
The fonts were a little better, but still the same. In total, 47 styles were used in the application. Of course, within one screen everything looked good and consistent, but throughout the entire application there were also enough duplicates and outdated solutions that were not used in the new designs.
This happened in almost all UI elements: styles, buttons, lists, section headings and much more.
Problem 3: Architecture
There were also shortcomings in the architecture of the application itself. UI and business logic were often in the same classes. We often encountered this problem when implementing new features: we had to slightly change the logic of an existing UI element, and for this we had to create a new descendant class. As a result, we increasingly increased the inheritance hierarchy and created more almost identical classes.
This made both onboarding new developers and feature development more difficult. The guys had to spend a lot of time understanding the existing code and not adding new bugs during development.
What we wanted to get from the design system
The number of such shortcomings had already become critical, and managers feared that it would seriously affect the user experience. First of all, with the help of a design system we wanted to solve the problems that I described above.
But at the same time, we wanted to achieve some strategic goals:
Accelerate the creation of design layouts based on a single library of components. That is, when a designer needs references for a new layout, he does not go through dozens of past projects, but opens a detailed guide where all the color combinations, fonts, shapes, technical characteristics and other necessary information are spelled out.
Simplify UI layout and appearance development. The design layout contains detailed instructions for interface developers – they act according to clear algorithms, which are collected in one document.
Create a single set of icons for the entire application. This makes life easier for design and development teams without having to search for specific icons throughout the application.
Unify application development processes. After all, a design system is not only about design, but also about the principles and organization of work processes.
How design and development problems were solved
To prepare the foundation for a working design system, we first needed to solve the fundamental problems that existed in the application. This is all a very slow process and took months of work. The information collected is enough for a whole series of articles, so I will describe the main points.
Colors, fonts and icons
First we dealt with the design chaos. Here's what we did for this:
We collected all the colors that are used in the application and divided them into two levels: hex colors on the first and semantic colors on the second. All code is tied to semantic colors. And if you need to change the shade in icons or individual themes, then we only change the hex colors – we don’t touch the code at all. This greatly simplified the modification and editing of layouts during work.
Next, we compiled a table for replacing colors throughout the application and wrote an import script that generates hex and semantic colors based on layouts from Figma. The screenshot shows the file where the values of all hex colors are stored.
As a result, we received 55 flowers – almost three times less than it was. Moreover, they all lie in a separate module of the design system, so there can be no confusion during layout. In addition, we have developed specific rules for using color combinations and the import script – when changing or adding colors, you do not need to transfer anything manually.
The same algorithm and tools were used to unify fonts and icons.
Now, during creation, the designer just needs to open the guide, and not look for references throughout the application – the time for developing layouts has been reduced by 30%.
Components
A component is a separate UI class that can be used for typical UI cases. It can be configured and reused across different application screens.
Components are important components of a design system, so I’ll tell you how we organized them in our project.
Each component begins with a description in Figma. It is formed by a team of designers. The designer describes all possible states and behaviors of the component, as well as what settings it has.
Next, the project is reviewed by a team of design system developers for different platforms (iOS, Android, Web).
After edits and approval, development begins: specialists (I am one of them) layout the component, set attributes, implement the logic of the component, its various display options and transitions between them, and then transfer all this beauty into the code. At this stage, the component is added to the developer documentation, which is located in our Android repository. For it, we chose the markdown format – it is convenient to view both from the browser and from the IDE.
Testing and more There are no special processes or secrets here, so I won’t dwell on them. More test cases are needed for a component, because its operation needs to be checked in the maximum possible number of screen sizes and all appearance states. After all, it is important to understand that a design system component is the basis for building the UI of the entire application, so it must work in completely different UX scenarios.
Interestingly, the components greatly simplify the layout of new elements. The picture on the left shows the code before implementing the component, on the right – after. 8 lines of code instead of 45 – the developer only needs to set all the attributes correctly.
All UI logic is already inside the components. And business logic is already created by our developers from product teams, depending on business goals. Thus, teams can use components independently of each other and not overlap in code.
Architecture
If earlier we had logic in one class, now we have divided it into two levels. Only UI logic was left in the design system components. Business logic is located in product modules, which use the components of the design system.
Main advantages of the solution:
We can reuse components in different application widgets without duplication.
Saves time on testing. QA now only spends time testing the business logic of a feature. And testing of the component has already been done in advance.
We have also collected documentation on confluence. There you can study general terms, look at the features of the application architecture, learn how to use automation scripts, and the like.
The process of further work on the design system
The design system is the foundation of the application. Therefore, it is important that representatives of all specialties who work directly with it take part in its development and improvement: designers, as well as iOS, Android, Web developers.
It is necessary to take into account in advance not only the visual component, but also the restrictions that different platforms impose.
The same goes for the development of each new component. You need to twist it from all sides and find a compromise option that can be integrated on all platforms without any problems.
Our organizational issues are resolved quite simply:
Once a week we gather for a meetup with the design system team. It is cross-platform – it has designers, as well as iOS, Android, and Web developers.
There is a separate channel in our internal messenger where we discuss current issues.
We communicate with product teams. They may send requests for the modification of components or the development of new ones. In these cases, we meet deadlines and agree on the integration of changes.
In general, we have a healthy communication process with everyone, because the design system greatly influences the visual component of the application and its entire performance.
What did you get in the end?
If we rely on the structure of the Android project, then our entire design system turned out to be placed in one gradle module. It contains all the classes of our UI elements (components, UI kit) and all other visuals (icons, colors, font styles).
There is also part of the automation there – our import scripts. Naturally, there is also the necessary documentation so that developers can immediately see how to use the components of the design system.
The design system is located at one of several levels in the project hierarchy. A fairly large number of modules depend on us, in most cases food ones. At the same time, the design system itself is as free as possible and in fact depends only on the various utility classes that it needs.
The result is a completely understandable and structured system in which you can easily find the necessary information both for the development of new components and design layouts, and for their implementation and integration.
And finally, I would like to separately highlight all the advantages that we received after implementing the design system:
On average, developers began to write 2-3 less code for the same tasks, so the speed of work has increased significantly. And the development of entire features has become on average 2 times faster.
The processes of design-assembly of layouts have accelerated by 3-4 times. Largely due to the fact that the time spent searching for the right colors, fonts, icons and similar design elements has been greatly reduced. Now you don’t need to search for them throughout the application – you just open the knowledge base and look at the required element.
The interface looks consistent. Each screen in the application consists of approximately 90% design system components. There is a common concept and style, there is no more variation in colors, fonts and shapes, and from a UX point of view, all elements behave completely predictably.
Onboarding of new specialists has become faster. In fact, now a new developer or designer only needs to study the necessary guides and understand the logic of the processes – in a week or two he will be able to fully get involved in the work.
Yes, in fact, we began to spend a little more time on testing components, but on the other hand, we save time on testing product features. Now we are almost finished refactoring the old widgets, but we still have a lot of plans. We are going to make even more components and detailed documentation on all the nuances of the system, create a library of animations and placeholders, and also expand the communications of the design system team with other Sound teams. This is necessary to respond to requests faster and further improve the foundation of the application.
And of course, there is a separate track on the transition to Compose.
Write in the comments if you have any questions. I will answer everything if possible.
