Building a Design System is a collaborative adventure

Introduction

Hey everyone, I am Armin, a Software Engineer at rebuy. In today’s article, I want to give you a small peek into our current development of implementing a Design System. I show you how we actually came to the point that we needed a Design system. Give you a rough idea of how to achieve this too, and bring your own Design System into your company. So let’s start the journey.

A glimpse into the past — 2022

Over the past few years, we have been working hard on improving our platform, making fast changes, and finding, with experiments (A/B tests), the right solutions for our customers. Our product is pretty stable, we are hitting a high crash-free-user rate of 99,995%, and we are doing a lot to avoid issues by implementing various automated testing methodologies, pair programming, and co-review every feature we are shipping to our customers.
Basically, we were pretty happy, but in one area, we spotted a weakness in our daily development. A missing Design System. On design-heavy tasks, we were lacking in development speed and overall UI consistency. So from time to time, some of our engineers came up with the idea, “Hey it would be nice to have a Design System.”, we then considered it, but we always stepped away from making this reality. We were asking ourselves, “Do we really need this?”, “Is it worth all the hassle?”, “Who will maintain this?” so the idea faded away often as quickly as it appeared. Don’t get me wrong, we had defined various styles for buttons, input fields, fonts, and more, but it was more of a wild ragbag than a well-thought-through Design System. We just patched everything together when we spotted some similarities. So basically, we had a design without a system.

The turning point

Around one year ago, the idea of a Design System emerged again. But this time, we were in a special situation and were facing a staff-related challenge where we switched from a pretty stable team size in the customer-facing area to a growth path where we were considering establishing multiple new teams. During this time, product management and engineering independently evaluated once again the need for a Design System, and our product management took the initiative to make this topic a first-class citizen.
We saw the need to ensure that our design language and usability for our customers are implementable throughout multiple growing teams and platforms like Web, Android, and iOS.
Our goal is to establish a rock-solid and stable Design System that supports us in our daily work and gives us general guidelines on how to build a nice-looking product.
On top of this, we were basically without a Designer for a certain amount of time since our beloved designer moved abroad to start a new life on the other side of the earth.
So we decided to set a new focus in the designer’s hiring process. From this point on, all new designers we were hiring should have already gotten experience in building a Design System or at least be willing to support the idea of building a Design System and show a high willingness to learn and advance in this area.

Bringing all together

We have experienced that bringing a Design System to life is a big team effort, and when you want to lift something similar in your company, you need to convince every party involved in this project.

Product and management

Having the product and management on board is an essential part of being successful with your intent of building a functional and healthy Design System. It is a huge investment in time and money to make this a reality. Even though god created the earth in six days, you won’t be able to rest on the seventh day because building up your Design System from the ground up will take some time.
It costs a lot of hard work and sweat to make this dream come true. The Design System is not something you can achieve by spending a few hours each sprint, and hope you can bring it to life. Modern web/app products are moving too fast; by the time you are ready with your first version of a Design System, it will most likely be outdated, and you will need to start all over again.
The Design System must be a first-class citizen in your roadmap and plans. You will need to sacrifice other projects that seem more attractive for the company to implement in the first place. A Design System is a long-term pay-off and nothing that will show its full potential after a few days or weeks.
So it is very important to have the management and the product on the same board. We hope for increased development speed, reproducibility, and reliability. These are the promises that we have made for the future, and we have to be taken accountable for this.

The developers

At least for me, this step seems to be the easiest part because I am an engineer. Although also here, you have to get some stumbling blocks out of the way. Not all developers are used to working with a Design System. Everything till now was built with a few loose, tight styles that were defined before. Almost every component that was built from a design is some kind of unicorn.
For example, the address forms in our checkout process and my account look and feel different even though they use the same backend logic. Developers will need to respect that the components set in the Design System are now the new standard and that they are the new single source of truth when it comes to building the UI. Don’t change the app’s UI, but change components in the system is the motto.
For example, we will only have 6 different distances defined in one central place (0px, 2px, 4px, 8px, 16px, and 24px), and everything will be built upon these distances. Unfortunately, in our old “style”, we counted 38 different distances/sizes that were defined and misused everywhere throughout the app.

The designers need

Also, the designers have a high interest in a Design System. The learning curve can also be steep here. When a designer previously was able to set the distance or corner radius individual per newly developed component a Design System gives clear restrictions and boundaries in which the designer can move. The designers themselves define these boundaries. But it might also get tricky from time to time to hold up the standards a designer defined for himself and the team. Every bigger piece needs to be built up on something already existing in the Design System. From small to big. The atomic design might be the right methodology and the answer for you and your team. Don’t give up here. Even it seems sometimes annoying to follow the self-set rules. Ultimately, your team and the customer will be rewarded with a well-thought-through and standardized user experience.

Everything only works when are all in the same boat and work as a team

A little analogy:
You can’t steer a sailboat and find an enchanted island with treasures alone. Everyone involved in this topic must be committed and passionate about this project. When it comes to exploring an enchanted island with treasures somewhere far away in the deep ocean thousands of miles away from your kingdom, you will need to get everyone aligned and on the same board.

• The Highness (The management) of the kingdom needs to be convinced, so he is financing your expedition. Giving you the time and the materials you need to make this dream come true. He wants to see a reward in the future that will bring him benefits and fortune. (This is the increased productivity that a Design System promises).
• The Captain (product owner(s)) is setting the rough direction of the boat, which he assumes has the highest potential of finding the island with treasures. He gathers the information from the grew and adapts the plans on the fly upon the newest findings.
• The cartographer (the designer(s)) will work alongside the captain to create maps (the design) based on the instructions he got from the Captain he gathered from the rest of the crew.
• The machinist (the developer(s)) will work hard on getting the boat to speed with the giving instructions they get from the provided maps and instructions to bring the team closer to the dream.

There might be times when storm waves will occur, and your sailing gets harder. Project priorities might change, and your mission gets paused temporarily, parts of the crew could get sick, or unexpected monsters (bugs) could occur. Don’t get demotivated by this, and think about the reward that the Design System will offer you in the future.
So, in the end, you see, building a Design System and sailing a ship to a treasure’s island have a lot in common. Just kidding, but I hope you get the analogy.

We are doing it to serve the customers

All the things we drive forward collaboratively daily, all the fun and the frustrating moments we experience throughout the process of building a Design System, are helping us to grow further on a personal and a company level. The positive critical thinking of everyone is something we value, and the personal responsibility and love everyone is taking in this project is outstanding. It is a lot of fun to see on a daily basis how we get step by step closer to a Design System that will persistently serve our customers with a consistent user experience and give us the freedom to move faster in the future.

Thanks for reading this article.