Starting a Design System in a changing company

“How are you ensuring visual consistency across your three products, and how do you document design decisions for everyone involved?”

I remember asking this question during my second interview for a job as a Product Designer. Their answer was uncertain, but essentially, there was no real solution to the challenge they were facing. The company had three products with different focuses, but they were all gathered under the same umbrella brand. They needed to be recognized as such and provide a streamlined experience for the end-users of those three platforms.

My immediate reaction was to think that it was curious and that the company had managed to design these experiences until the time of the interview, so it must be alright. This marked the beginning of my journey. Let’s dive in!

Status Report

The first part of the journey is all about assessing my environment. I got the job, so now I can fully immerse myself in how the company has organized its design resources (assets, tools, coworkers) to make it work and identify actions I can take to solve any issues. Being a Product Designer is a great asset, and being familiar with UX research methods makes it easier to identify underlying issues the team and process might face.

I organized a series of interviews with both designers and developers. They were organized in two parts, first I tried to get a glimpse at the way they interact with each other by letting people talk about their job. I then started to ask more specific questions about the handoff process, asking them to give me concrete examples of how they are experiencing it. There were three main benefits of doing these interviews:

1. Get to know the people This is equally as important as learning about design systems in general. They are the ones who will actively use the design system in their job, they are the primary users. It was also a good way to learn more about the company’s history if it attempted to create a design system in the past and why it failed.
2. Identify issues As a designer myself, I am biased when it comes to the issues I want to solve with a design system (find up-to-date documentation, find the right version of a component or an asset…). Having these talks gave me a more accurate overview of the situation, developers want to find the right documentation for the components designers are providing and they want to be able to save time instead of coding the same thing multiple times across different projects.
3. Get to know how they work Maybe a design system is not the solution, maybe it is. Knowing what developers and designers use to make their collaboration work is key to this project. I got to know that front-end developers have a repository with components, great! Except that updating it was deemed very cumbersome due to a certain amount of technical debt and that these components were not shared with designers.

In parallel with this, I got to read a lot of papers and books about design systems, some very general, some very specific. The ones that I could recommend for anyone getting interested in this topic would be Design System by Alla Kholmatova and Laying the Foundations by Andrew Couldwell. Having most of the information I needed to form a better idea of what could be a design system (at least the start of it) in the company, it was time for the second part of this journey.

Getting buy-in from decision-makers

No spoilers, this one was extremely difficult — and not fully covered. If I have to retain one learning from this experience, it would be that this stage can take much longer than planned and that it is never really completed. You have to update the stakeholders on where the design system is going and give them an overview.

The company holds once every quarter an “innovation week”, where engineers and designers can work on any topics that they like. I obviously chose to work on a design system MVP. During this week, I managed to successfully code a design system prototype using React and Storybook for the components, Figma and Tokens Studio for the designs and tokens and GitHub to store everything in one place. I was very happy with my project and presented it to the audience (90% of them were engineers). The project stayed pretty much like it got presented — not having the time to work on it was the main issue for me as I was still doing my regular Product Designer job.

I did not stop there, there was another instance where I could raise awareness of the benefits of a design system in the company — it was just like the innovation week but focused on the business side of these projects and how they could benefit the company. After this presentation, I remember asking myself why I did it in the first place — knowing that a design system was not the priority now for the company. I went forward with it to bring awareness around the issues designers and engineers had — and it was well received. The initiative has not been deemed of priority (just as I expected) but it has been decided that it would be an ongoing initiative that could not be bound to a quarter. After talking with my Design Lead, I went on and worked on the design system when I had time.

From time to time, I would have a chat with the Creative Director on the importance of a design system and how much we need it. Sometimes it was with the CTO, being excited about the things to come with the design system. These interactions were always informal, they gave me the impression that these important people in the company were backing the project. But as mentioned, it was informal and nothing official. This should have been a sign for me to clarify the situation. It was the first issue that needed to be fixed, soon, more would follow.

The struggle awakens

Know where to start

Now it was time to actively work on it. The topic is so broad that it seemed difficult at first to know what to work on to have an impact. I decided to work on both sides of the coin, our libraries in Figma for the design side and a documentation platform for the engineering side. Here are some examples of tasks I worked on:

Design side:

• Organize our assets in libraries to easily update them and bring clarity to their updates.
• Flag outdated components in their name (for the search) and visually.
• Add documentation to critical components (button, controls…)
• Create Design Tokens

Engineering side:

• Find a documentation platform that supports Design Tokens (Supernova was the one I settled for).
• Set up a simple flow between Figma and Supernova to update tokens.
• Code boilerplates to quickly test design tokens in code.
• Store tokens, boilerplates, and icons, on GitHub for engineers to access all of the data.

With experience now, I can say that, in this setting, it was a mistake and I should have tackled the design part first and then the engineering part. I would have worked on the design side first because it would trigger the rest of the design system. If the design team is organized, building a design system becomes easier (it is still not easy, just easier).

Resources issues

I talked about the “setting”, it was part of why building a Design System in this company was predestined to fail. I was the only designer pushing for it and having the will to code (and learn) in the design team. This reduced drastically the impulse this initiative needed. I was not working 100% on it, because I also had to do my regular job, what I have been hired for at the same time. The deal I made with my Design Lead was to work on the design system on Friday, when I have nothing else urgent to work on. It quickly became a fantasy and I could effectively work on the design system roughly once every 2 weeks.

From the engineering side, there was an initiative to update the tech stack we had but it was not a “design system initiative”, but more of an update. There was one front-end engineer working on this topic so we coordinated our efforts and updated each other on what was going on for each initiative.

There’s so much one can do, especially when you are driven by the topic. I could not make up for another designer, and I couldn’t become an engineer despite knowing how to code. I didn’t know our tech stack in detail or the processes around it.

In the end

In the end, I managed to organize our Figma libraries, set a flow between Figma and Supernova, store all of these values on GitHub for everyone in the company to use, documented 15 components, and shared regular updates in a dedicated Slack channel — but all of that was not enough to set the design system afloat. Not having the resources to work on this initiative (time, people) was critical and did not set us up for success. I also wanted to do too much all at once. Now I know that and I would not go down the same path — it’s a lesson learned. I left the company for multiple reasons but I am not sad about what I tried to achieve with the design system. If I had only one wish looking back at this experience, it would have been to have more support from the company — at times it felt like I was alone dealing with it. It was a very valuable experience and it doesn’t deter me from moving closer to DesignOps in the future — it actually convinced me that it is what I want for my career.

🧑‍💻 This story was originally posted on my website. 🆇 Follow me on X!