Our internal research for a new design system & tips on how to do it

When we were defining a design system project, our goal was the usual one — to increase the speed and efficiency of our teams by improving consistency across our products.

Photo by Andrew Neel on Unsplash

Before we started creating the design system for Kiwi.com, we went looking for inspiration. One of the most inspiring sources was probably the public design systems from other companies. Some approaches to, for example, colors and typography were particularly appealing to us. We were amazed by the level of detailed documentation. But we also quickly realized that, even though the knowledge there is really great and it can significantly help us later, it lacked our specific context. The Kiwi.com context of designing for travel-related products.

Someone else’s design system doesn’t have to work for your team requirements.

It’s important to realize that public design systems are basically solutions. Each design system is a specific solution to the problems of another company and is influenced by their unique culture. Someone else’s guidelines may or may not solve the problems that we have here at Kiwi.com.

Of course, we saw that we lacked consistency across our products. That our product teams repeatedly solve very similar problems like which color to use for a button or what icon to use for a passport. These discussions are time-consuming and mostly redundant.

So we slowed down a little and planned some internal research.

Internal research

A huge part of our internal research consisted of interviewing stakeholders. The main goal was to expand our knowledge of the way product teams work and communicate. The other goal was to find out what people expect from an emerging design system. We also needed to find things that would be the most beneficial for us. Find the problems that are easy to solve and create an MVP that would help us in the shortest time.

Stakeholder interviews, of course, weren’t the only thing we did when we were researching design systems. Another very important part was conducting a UI audit and documenting what we had already implemented in our product. This was important for us — mostly because we found out that besides having a really inconsistent product, we also had a lot of different marketing landing pages. This was the primary signal for us to reduce the scope of our design system and to focus on our main products only.

It also meant that we knew we would need to solve this landing page problem later and that the marketing department would be a new group of stakeholders. But we chose not to focus on this part in the early phase of our design system.

People

The first question we asked ourselves was “who will work with the design system?”. These would be the most important people to us. They would be our stakeholders. If the design system would not work for them, it would not work for anyone.

Our group of stakeholders included about 10 people, so it was manageable to do interviews pretty quickly. If you want to do it with fewer people, it’s totally ok. Just be sure that you talk with a diverse group of stakeholders to get different points of view. We spoke with all the designers and leaders of our frontend and mobile teams. Most of the conversations took place over a cup of coffee or tea, which really helped us keep those interviews more friendly and casual.

Photo by Mario Ibrahimi on Unsplash

It was also important for us to get in sync with our CPO and a few product managers. Why? Because the design system will have an impact on the product and its processes. It’s also a great opportunity to promote the way it will help deliver things faster in the future.

Internal research is a great opportunity to promote the benefits of the design system.

The first thing that stood out was that there were lots of different expectations of what problems our design system should solve. This was a strong signal for us to prepare to communicate clearly what we are trying to solve and how we want to approach it.

During the interviews, we also found out that there is a lot of design friction between our website and mobile application. Many people also said that the mobile and desktop teams don’t communicate a lot. Based on that, we interviewed more people from the mobile team. The goal was to find out more about this issue and based on these insights, create the strategy of addressing it.

What would we do differently when selecting stakeholders? There is one group of people we would include in the first round of interviews next time — frontend QA testers. Why? Our QA testers have a direct contact with everything that developers want to release. This means that they are a really important part of our release process. A QA’s work is basically reporting anything that isn’t ready to be published to production, so they see a lot of repeating issues.

Questions

The internet is full of information about design systems, not much about stakeholder interviews before starting with one. On the other hand, we need to say that it’s not rocket science at all. When doing any research, the most important thing is to realize what the main things you want to know are.

For us, it was the understanding of how our designers and developers work together. We wanted to know in what manner the design system can make their jobs easier. So we focused on understanding which tasks people need to do every day and which parts can be improved or automated. Last but not least, we wanted to find out if there is anything we need to be prepared for. These interviews actually influenced our future communication about the upcoming design system a lot.

The design system’s job is to make other people’s work easier.

Once the conversation gets going a little, what are some of the questions you can ask? This is definitely not a full list, but it might give you some direction.

• What are the things that take you the most time in your daily job? What is the most boring stuff you have to do?
• Do you have any job routines for them? How do they help you?
• How do the current design handoffs work? How do you handle specifications for designers and developers?
• How do you share your assets with designers?
• What do you think our design system should have? Why?
• Do you think that the design system will somehow change the way you work? How?
• Have you worked with a design system before? How was it?
• How could this whole activity go wrong? What do you think the biggest problems will be? Is there anything you don’t like about the idea of having design guidelines?
• What do you recommend in terms of the flexibility of components? What do you think about more than one variation of a component? Is it technically possible?
• What do you think about our current visual style? Should we create a new visual style with the design system or continue with our current style?
• On what level can we share components between our website and mobile applications? What do you think about having one visual style across multiple platforms?

The goal of these questions was mostly just to open some topics and let people talk. Be honestly curious and you’ll see that people are eager to talk about their jobs.

It’s important not to be afraid to ask additional questions when something appears. Be there, listen and be supportive when people answer. One small tip — record those interviews, it can help a lot when going through the notes later on.

Be honestly curious about your team members’ jobs.

It was important for us to draw a little attention to the idea that we should measure our design system. Why? A great amount of resources and time goes into the creation and maintenance of a design system. We should have data to prove that it is helpful instead of relying on feelings. So we added this question — to make people think about it a little.

• How can we measure the success of our design system? Do you think it’s important? Why (not)?

Photo by Bookblock on Unsplash

Insights

This research was a great way of understanding some processes of design and development. We were also very positively surprised with a lot of insights and how quickly it helped us get on board with everything that was happening.

We would love to mention three insights that probably surprised us the most:

• How much it helped us understand some darker corners of Kiwi.com UI and realize what stuff we keep doing over and over.
• When we talked about consistency, most people mentioned consistent interactions and behavior. The visual consistency was taken as a matter of course.
• One of the main fears was that because of strict guidelines, we would make compromises with solutions and that it would affect our users in a negative way. We were quite happy about this one, it has shown us that our people have a very healthy way of thinking.

Another important thing we discovered was that we already had some things on the move. There were ongoing projects for syncing our color palette or redesigning our buttons. Designers used some tools for syncing assets as colors or typography. We already had a few Sketch files with the most used components like form inputs. But there wasn’t any common vision behind all this. It was isolated, not connected to each other. We knew that our job would be to turn it into a more coordinated activity.

Let’s sum it up

We gained a lot of insights from our research and explored public design systems later again. What was different this time? We already knew what specific problems needed to be solved with our design system. Because of that, we were able to look for inspiration through our own eyes, with our point of view. It was not only an interesting, generic approach to colors, but rather something that would inspire us in the context of our company and design system.

Transparency is important, don’t hold any information back.

Last but not least — after the research was done, we presented the most important findings back to the team. It was a great opportunity to get together and talk about the following steps. This research showed us that we need to be very careful with the scope of our design system and not to think too big in the early phase. It helped us realize what our MVP should be and influenced our design system roadmap significantly.

If you like what you have just read, give it some claps 👏 please! More articles about building our design system are coming. You can also follow our design team on Twitter.