Jeannine Endreß / 30 Sep 2025
In the past few days and weeks, it’s been hard to miss the debates about Apple’s new Liquid Glass design. Some few people love the fresh look, others find it — let’s say — distracting or over the top.
If you’ve updated not just your iPhone but also your MacBook, you’ve seen how the Liquid Glass design carries across devices. From the very small screen on your wrist over the small smartphone screen in your hand to the larger one on your desk, the new design system creates a unified experience that feels intentional.
Apple’s “Liquid Glass” design: love it or hate it, it’s everywhere. From your pocket to your desk or even living room.
Design Systems enable high reuse, they increase the delivery speed.
But they add clear constraints and therefore, reduce flexibility (in visuals, releases, updates).
Make these trade‑offs explicit and governed!
That’s where things get interesting. Apple has to perfect their look for multiple devices and therefore screen typses, but only for one brand.
Most companies, however, face a tougher challenge: delivering polished, consistent experiences across multiple brands, products, and screen sizes. Meaning, without a strong multi-brand design system that challenge quickly turns into chaos!
We’ve spent years in the trenches of automotive and mobile projects, watching what works and what crashes (spectacularly).
From that experience, we’ve pulled out three big lessons. Not theory. Not pretty slides. Real, implementation-proven principles that save product teams and companies from painful mistakes.
One design system, many screens: from the driver’s display to a panoramic passenger screen.
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.
Always check the consequences of a decision against the level of (added) complexity.
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!
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.
Clear ownership and rules are essential for the successful development and maintenance of a multi-brand design system.
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.
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.
Think of multiple (hardware) generations when building a multi-brand design system.
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.
Jeannine is an IT consultant, passionate writing about digital privacy and mobile apps strategy with a focus on empowering women in tech.
Jeannine Endreß
Next up
Blog
To find the real business case for MCP, we must look past the technical plumbing and examine the economic lever. Why are pragmatic engineering organizations like Block and Stripe investing here? It is not merely engineering hygiene. It is an attempt to solve two expensive enterprise problems: productivity at the edge and integration at the core.
Blog
Many companies are already exploring what AI can do for them. We observe a rise of GenAI uses cases that automate the process of extracting information from documents, know as document intelligence. When it comes to document intelligence, companies often turn to methods such as Retrieval Augmented Generation (RAG) to pull insights from documents. Discussions on RAG often overshadow other aspects of the process. Recently, we had the chance to push the boundaries of Document AI to automate a labor-intensive manual process. Here is what we learned.
Blog
Today, we can build apps inside ChatGPT using prompt engineering. But the real transformation is happening one level deeper — with MCP servers and the ChatGPT Apps SDK, which let you deliver fully interactive applications directly inside the chat interface.