It took almost 6 months, but by the end of 2020, we greatly simplified the colours in our design system with an iterative process. Changing the foundations of a design system without a dedicated team is hard, and I want to explain how we, as a group of engineers and designers, got past them.
Help your engineers
EyeEm hasn’t got the resources to have a dedicated team for building and maintaining our design systems. My job as a product designer is to support my team in building features to make money for the business. When we first started building the design system, I actually felt guilty working on it. “Does my boss approve?” was ever-present in my mind, doubting my own ability to properly prioritise my workload. This feeling gradually went away with each contribution leading to a greater reaction from our engineers. The lesson learned was to grow our design system; I needed their support by solving their issues. In practice, solving an engineering problem often solved a design problem, so I was doing myself a favour by aligning with engineers. Redesigning our palette is a good example; both engineers and designers thought we had more colours than necessary, adding cognitive overhead when choosing a colour to use.
Before you read on, I’ve created some definitions for certain words I repeatedly use throughout this post.
- Theme: A named object containing tokens, e.g. “light” or “dark”
- Palette: A collection of themes
- Token: A property within a theme that’s defined by a colour value
- Unknown: A colour value that isn’t a token stored in our theme
- Functions: A method of generating unknowns or tokens using a token as a parameter
This is mostly inspired by Brent Jacksons The Design Graph post, and I encourage you to read his work if you are interested in design systems.
Diving into the codebase
First off, I needed to know about the problem in more detail. The research scope was two repositories, our design system EyeEm UI and our Frontend repository. The exercise itself was visualising in Figma how many times we used a token; on completion, I shared my findings to the lead designer Alessandro and senior engineer Claire. It took some time, and it was all manual work, but it was easy to do alongside higher priorities.
When searching through Frontend, I found that we only used about a half of our tokens in our palette. Luckily, I could see the engineers were using this small selection of tokens consistently, meaning any potential breaking change we may inflict on Frontend at a later stage wouldn’t be a big deal to fix. Tokens weren’t used equally; in some cases, tokens were only used once or twice. To make our redesign easier, I wrote a ticket(a) to migrate those cases to a more commonly used token.
Our components in EyeEm UI used even fewer tokens than Frontend. This wasn’t surprising because I knew many components were generating unknowns from functions instead of using our tokens. Side note, each theme in our palette contained about 29 tokens, 14 of which were also generated with a function.
It’s obviously not great that our components are using unknowns, but the real downside I saw with using all these functions was that only one theme could look good. Our default theme is dark; however, we still needed a light theme for many reasons, and the use of these functions gave us no control over our light theme. Using functions made sense back in the day because we saw our light theme was an edge case, something that will go away soon. However, times have changed, theming nowadays is the sign of a ‘modern client’, so if we wanted to follow this trend, these functions would have to go.
Continuing my investigation into the EyeEm UI repository, I saw many functions generating very similar unknowns. This type of repetition makes any major redesign harder to do, so I wrote another ticket(b) to lift all common styles into a Variant file that components can utilise. My goal as a designer is to make sure our design system is consistent, but these tickets also reduce code complexity.
By the end of my investigation, I concluded that our palette wasn’t aligned with our needs, forcing us to break away from it. Those two tickets(a & b) weren’t going to solve the problem, but they will make our lives easier when the real work begins.
Creating a plan
It was around this time when my colleagues started to involve themselves with the project. Claire would handle the engineering work, and Alessandro would decide each token’s value. We had our goal “to have a simpler palette that scales consistency”, it was my job now to find a path forward. It’s not feasible for product teams at EyeEm to focus entirely on design system tasks, so I needed to break the work into small pieces that could be spread across many sprints.
This is how I planned it
- Redesign our EyeEm UI palette.
- Update Frontend
- Change the values of our EyeEm UI tokens.
- Update Frontend again.
Splitting up the tasks by repository makes it easier for a team to estimate the complexity, not to mention the tasks are just easier to complete. By the end of step 2, we would’ve already solved our original problem, and by the end of step 4, our themes would look great. Alternatively, we could have planned the project out, so Alessandro and I would develop a new palette before any development started. This would’ve resulted in fewer tasks to complete, but each ticket could have been more complex, potentially increasing the chance for unforeseen issues. In my opinion it’s better to have a continual sense of momentum even if we make mistakes along the way — which we did of course.
Redesign our palette
We wanted both great light and dark themes for EyeEm UI, and the first step was to statically define every token needed for both themes.
Components generating unknowns now had tokens they could use instead, and the function generating tokens could also be removed. As it was before, each theme had identical tokens, but now the value of a token could be changed without it affecting the other theme. Ticket(b) made removing these functions easier because we dried up the styles beforehand using our variant file.
Claire and I also came up with a new naming convention for our scale, which would be a breaking change for the Frontend repository. We talked at great length about whether we should name our tokens functionally like ‘text-primary’ or generically like ‘grey100’. Functional names sounded great to me, but Claire made a fair point that it could result in many tokens having the same value. We chose to name our tokens generically in the end because it would shrink our palette a lot but give us the flexibility to scale in the future. If your reading this wondering what the “right” way of naming colors is, go speak with your engineers first because they probably have an opinion about it.
Update frontend
Now it came to updating Frontend to the new naming convention. The ticket I wrote explained what each old token mapped to, but I drew a diagram in Figma to be crystal clear. With the completion of this task, the developers got a much-improved palette to work with, the themes themselves didn’t look perfect, but that will come after. As a whole, this task was made a lot simpler because we finished ticket(a) beforehand.
Change the values of our tokens.
We had the palette structure defined — now we can adjust. Alessandro wanted to use this opportunity to introduce an accent colour to our web services. To keep the search for this accent colour productive, we agreed on a few principles. Firstly, this accent colour needed to work well for people that suffer from different types of colour blindness. Secondly, the contrast ratio should exceed our baseline when used for text and or UI. We chose iOS as our baseline because its such a ubiquitous design language that aligns with our aesthetic tastes. We didn’t design our palette to meet high accessibility standards, but we rigorously tested each colour to finalise our choice.
The diagram shows that we introduced another breaking change by migrating certain tokens to a new token group titled “aqua”. This isn’t exactly how it went in practise; rather, we kept the old tokens in the design system but migrated all our components to the new aqua token group. This would enable the Frontend repository to use the “deprecated” tokens until we wrote tickets to migrate away from them.
Update Frontend again
I have to say I borked this last part pretty hard. We were halfway through a navigation redesign when I decided to update the design system version of that features branch. I was confident that updating the design system wouldn’t do any real harm, but I also didn’t give our QA engineers any heads up. They were somewhat surprised to see all the colors on our app have suddenly changed, expanding their test plan for this new navigation — sorry, Stratos and Orestis!
Summary
I’m definitely happy with the outcome we reached, but I would say the process of getting there was the exciting part.
Here are the insights I took from the project.
- Regularly speak with engineers and designers about their design system issues. The more problems you address, the more vocal they get.
- Get to know your design system’s codebase. Understanding how it works tells you how to improve it.
- Always come to backlog grooming session prepared with new design system tickets. It doesn’t matter if the tickets are big or small — progress is progress.
- Be patient. Having no dedicated design system teams means you have to juggle higher priorities.
- Be aware that a Design system isn’t just a component library. It’s a service for people to use, so make sure it’s intuitive and straightforward.
Scroll down below to see some before and after screenshots.
