The design system behind the company’s web products

Bjorn Lunden builds several web products, and some of them ship under more than one brand.

Each product had its own look and its own behaviour. Developers built the same components again in every product, and designers redrew them file by file. There was no shared library in Figma or in code.

A brand change meant editing every product by hand. A separate copy of the interface for every brand and market doesn’t scale.

There was no dedicated team. We built the system next to regular product work, and against a fixed launch date.

Older products couldn’t move over all at once, and the same tokens had to work in more than one codebase.

A shared design system used across the company’s web products. Designers and front-end developers started it together, as one planned effort.

My part was the tokens and theming, the Figma library, and the direction and process. Today I look after it: deciding what goes in, setting priorities, keeping design and code aligned, and helping product teams adopt it.

Tokens carry the theming, so one set of components serves every brand without a fork.

Tokens named for their role. Components read tokens like headline and card, not raw colour values and not a variant per brand.

Modes, not files. Brands, light and dark are variable modes in one Figma library, not one library per brand.

One name per token. A token is called the same thing in Figma and in code, so designers and developers mean the same thing when they say it.

A small group decides what goes in. Product teams don’t each add their own components to the system.

Contrast is checked on the tokens, for every brand in both light and dark. The focus ring is a token too, so every brand gets a visible focus state.

Keyboard behaviour, labels and ARIA are built into the components. A product team that uses a component gets them without extra work.

A design system that only exists in Figma is a style guide. We agree on tokens together, then work in whatever way fits the component: a designer and a developer paired on it, or design first and build after with close back-and-forth.

Handoff is never done. We keep improving how it works, and we keep track of where the components in Figma and the components in the code differ.

I lead on the UX/UI team, and part of that now is helping the design teams and the product department find practical ways to use AI.

I use agents to build working prototypes from the real components, to compare Figma with the code and find where they differ, to draft component documentation, and to summarise discovery material. This site is built and maintained the same way.

I teach it in workshops, by pairing on a colleague’s real task, and by sharing setups that others can reuse. Prototypes reach testing sooner, more designers build their own, and differences between Figma and code get caught faster.

The question I keep asking is when to let AI explore and when a trained eye has to make the call. Faster only counts if the result is still good.

I led the rebrand of the company’s products with marketing and business development, and was part of the coordinated launch under the new brand, including in the Netherlands.

We had already started building and using the design system when the rebrand came. The new brand still asked for more: new components, a new token setup, more variants and more documentation.

Most of the company’s web products are built with the system today, and more than one brand runs on the same components without a fork. We now have a solid foundation that will scale with future needs.

I’d track where Figma and code differ from the first component. We started later and had to catch up.

I’d also start with fewer tokens, and add one only when a real need shows up.