The problem

For design system, complexity is like weeds. Leave it unchecked when taking a decision and soon you’re drowning in tokens, variants, and components that nobody can maintain.

In multi-brand systems, this problem grows exponentially:

brands × themes × screen sizes × component variants = chaos

If your release cycle additionally depends on hardware variants and regular updates are difficult like it is e.g. in the automotive industry, you quickly end up in complexity hell.

What works

In multi-brand systems, this problem grows exponentially:

Cut ruthlessly. Ask for every decision you take: “Do we really need this new token / variant?” Most of the time, brand identity can shine through a few well-chosen tokens instead of thousands. You need to motivate your designers to becoming extra creative and work with the toolbox of components and variants you have. Don’t build custom components and variants. If you are tempted, calculate the price tag. (And I promise, you won’t give in to the temptation.)

Decide early. Lock in your common set of components. Really take the time and discuss with your designers, developers and product managers which components are required to build the user experience you want to provide. Agree on a set and stick with it.
Also decide on the theming strategy, token structure, and component APIs as soon as possible. Changing it later will result in a huge technical debt, or a lot of time to refactor and clean up.

Prove it fast. Since taking the decisions talked about in the last paragraph just from theory is impossible, you have to build a proof of concept that hits your toughest use cases (tiny driver display + giant panoramic screen with most different branding strategy, for example). You’ll discover real constraints much earlier saving you headaches down the road.
Taking the time to really lay a solid foundation, will make you exponentially faster down the road!

The problem

Without clear ownership and rules, design systems drift. Components fork. Tokens get misused. Names get messy.

Developers stop trusting the library and start rebuilding things themselves.

What works

Your design system is a product. Even if it’s only internal. Treat it like one!

Treat it like a product. Give the system a product owner, a roadmap, and quality standards. And make sure that your product owner understands the technical complexity. Give them enough power to protect the design system from unwanted derivations. Motivate them to keep the guidelines and limits alive.

Lay down the law. Decide naming conventions, states, and token rules before building anything.

Reuse beats reinventing. Say no to one-off components unless they benefit the whole system.

Automate + document. Continuous testing, visual regression, living style guides, all these tools keep your system clean and trustworthy.

Over-communicate. Share release notes, breaking changes, and roadmaps. Trust dies in silence.

The problem

Many systems are built to survive the next release and the current hardware, not the next five years and not the next hardware generation. That’s when redesigns, reimplementation and scaling issues explode costs.

What works

Design for every screen. Every component should gracefully scale from your smallest to your biggest screen. Without customisation being required! Each extra token costs you a little fortune down the line.

Evolve, don’t restart. Avoid big-bang redesigns. Small, continuous improvements are cheaper, safer, and let you learn faster. Besides, your underlying codebases can handle continuous, backwards-compatible improvements much more sustainably.

Tie choices to business value. Don’t just say “this is better.” Show the impact and estimate the price tag. This helps you deciding whether it is worth it.

• Multi-brand design systems are hard.
• They’re messy, political, and technically demanding.
• But if you tame complexity early, set up strong and reasonable governance, and design with the future in mind, the system becomes more than a component library. It becomes a competitive advantage.
• We’ve learned these lessons by building them, breaking them, and fixing them again. If you have similar challenges and want to benefit from our experience hands-on, reach out.