Three weeks of tokens, four years of design system

When I joined Celonis in April 2022, the design team was in the middle of moving from Sketch and Abstract to Figma. Which is a polite way of saying: there was nothing to move. No tokens, no reusable primitives. Just a freshly relaunched product and a lot of Sketch files.

Three weeks

Together with my colleague Marta Conde, I built the complete token architecture in about three weeks. We looked at the product designs from the relaunch, pulled out what was actually being used, and turned it into a structure: a primitive layer and a semantic layer on top.

We also talked about a component layer. And decided against it. For our context, the semantic layer was enough, and everything else would have been complexity for its own sake. Everything started in light mode only.

The ugliest part wasn’t technical. It was the time pressure. Three weeks for a foundation that an entire product would stand on is not a lot of time to be wrong in.

Then the actual work started

Tokens are the part people put on conference slides. The real work started after.

Components first. We built them on base components, which was the way to do it back then. Real native slots didn’t exist in Figma yet, so we had to come up with our own workarounds for the cases our product needed.

And then onboarding, a lot of it. A whole design team had to learn a new tool and a new way of thinking at the same time: why color-text-subtle and not grey-500, which token goes where, and why that matters. Trainings, office hours, reviews, again and again.

What we deliberately didn’t do

We didn’t add complexity just because we could. No component token layer from day one, even though it looked very professional in other people’s talks.

Instead, we put that time into onboarding. Especially for the custom components that product teams kept building during the transition. We couldn’t stop them from existing, but we could make sure they at least used the right tokens. That paid off more than any extra layer would have.

Innovation versus consistency

The resistance was the classic one. Product designers want room to innovate, a design system wants things to be consistent. Both are right, which is what makes it annoying.

What helped: leadership being very clear about the goal. If the product should become more consistent, the system has to be stricter, less loose. There was some pushback at the start. But we ran the design system team in the open, and product designers always had a way to push new ideas into the product, through custom and community components that could later graduate into the system.

About that 99%

Before you’re impressed by the 99%: it was mandatory. Leadership made it a clear requirement that things get built with the design system. If you didn’t, you had to argue why. That’s how you get to 99%. Not with a beautiful documentation site.

The faster-to-market number is the one I’m actually proud of. Because the components were stable in design and in code, teams stopped rebuilding the same things, and we could calculate how much faster features shipped. Up to 70%.

What went wrong

One: too much design system, not enough product design. You can build components in Figma that are perfectly scalable and beautifully slotted for the design system. But real product design has to be fast sometimes. When a release is due on Friday, nobody gives a shit about a perfectly slotted container. It gets detached, and the designer moves on. I underestimated that for too long.

Two: we decided things in design without looking at the code. Partly that was down to how our team was set up, but we made design decisions on our own and assumed the code would follow. In the medium term, it didn’t. At some point we had real breaking changes in our designs, because we had to adopt code structures that nobody was allowed to touch.

Code is key. Design is the flexible part.

With component contracts and AI, I wouldn’t approach it like that anymore. In our defence: this was almost four years ago.

The team

I led the design system team: three designers in-house, plus up to three external designers who joined for documentation and other scopes. On the engineering side, I shared the lead with our engineering lead, with up to six developers dedicated to the system. Design and engineering as one team, not two teams sending each other tickets.

What I’m taking to Unblu

Code first. AI takes a lot of work off our hands, and that makes a solid foundation more important, not less. And by foundation I don’t just mean tokens. I mean processes.

Building components with contracts isn’t the hard part of a design system anymore. The operations around it are. That deserves its own article, and it’s coming.