Work
E.ON Drive
Design lead, design engineer 2022–23 Built & led team of 3

One codebase, every brand, run by a team of three.

E.ON Drive needed to sell charging across its own brand and a major automotive partner, across countries. We built one React-and-tokens system that did all of it, lean enough for a self-sustaining team of three to run.

Multi-brand architecture React + tokens Lean operating model

E.ON Drive multi-brand web experience
2 Brands live from one codebase. E.ON and a German automotive brand.
1 Codebase for all of it. React and tokens, every brand from one build.
3 People to keep it running. One designer, two devs.
days hours For a brand or visual change to reach live code.

The problem

Many brands, many countries, one small team

E.ON Drive sells EV charging across an ecosystem of products. Some under its own brand, some co-branded with automotive partners, on web and in an app, across multiple countries. Every brand wanted its own look. Every market had its own needs. The usual answer is more codebases, more people, more drift. E.ON Drive needed the opposite: a system a small team could keep running on its own, without any of that.

THE PATH WE DIDN'T TAKE Brand + market needs Brand A front-end Brand B front-end App front-end Per-market front-end drift + work ↗
THE PATH WE DIDN'T TAKE Brand + market needs Brand A FE Brand B FE App FE Per-market FE drift ↗ + work ↗

Separate front-ends per brand and market: duplicated work, and they drift apart over time.

My role

What I owned

I led the design-systems work as freelance Design Lead. I set the architecture and built the token model that let one codebase wear different brands, and worked alongside two developers to turn it into real, shipping React components.

Just as important as the architecture, I built the team and the way it worked. I set a lean operating model: how design and code stayed in sync, who owned what, how a change travelled from Figma to shipped. The point was never a big design-system team, it was one small enough to keep moving fast and not become a slow-moving beast, which is how three people kept a multi-brand system shipping across the Nordics.

The effort was front-loaded on purpose. Heavier up front to get the architecture and tokens right, so that once it was ready for primetime the system scaled down to a barebones team of three to run and extend.

The approach

Unbranded by default, branded on demand

The core idea is simple: build the system unbranded. Components know nothing about E.ON or any partner. They just know structure, behaviour and accessibility. Brand lives entirely in design tokens. Swap the token set and the same component renders as E.ON or as the partner, in light or dark, without touching the component itself.

We wired the tokens straight into custom React, so a change a designer made in Figma flowed to real coded components instead of becoming a developer ticket. A colour fix that used to mean days or weeks of re-implementation became a same-day change. The system did the repetitive work; the three of us did the thinking.

A design system is a product that serves other products. Get the foundation right and the team stops reinventing the wheel and starts shipping.

ONE BUILD, EVERY BRAND Unbranded build React · no brand run by a team of 3 Brand token sets E.ON · Partner E.ON · light E.ON · dark Partner · light Partner · dark
ONE BUILD, EVERY BRAND Unbranded build React · no brand run by a team of 3 Brand token sets E.ON · Partner E.ON · light E.ON · dark Partner · light Partner · dark

One unbranded build, themed by a brand's token set into every brand and mode. Run by three, live across the Nordics.

The outcome

Live across the Nordics, and runnable by the team that stayed

The web experience went live multi-brand across the Nordics: E.ON Drive and a German automotive brand, fully responsive, all from one codebase maintained by three people. A new brand was a new set of tokens, not a new project. A visual change reached live code in hours.

We designed and built the companion app too. It worked, and then the wider programme was cut before it shipped. The web system stayed live, and the team kept running and extending it without me. That was the point: build the foundation right, hand it over, and let a small team carry it.

The E.ON Drive vBox smart web experience on a laptop, built from the multi-brand design system.

Questions

What does "unbranded by default" mean?

The components carry no brand, only structure, behaviour and accessibility. All brand lives in design tokens. One component can render any brand by swapping the token set, so you maintain one thing instead of one per brand.

How does a design change reach live code without a developer rebuilding it?

Design tokens are wired directly into the React components. When a designer changes a token, the coded component updates from the same source of truth, with no hand re-implementation, so a change lands in hours instead of days.

Can three people really run a multi-brand design system?

Yes, if the architecture does the heavy lifting. With an unbranded component layer and tokenised brands, adding a brand or a mode is configuration, not new code, which is how a team of three kept two brands live across the Nordics.

Add brands and markets, not people.

One build wears every brand, and a lean team keeps it shipping, by design. If you are scaling across brands or markets faster than you can hire, let's talk.

Get in touch