One Look, Many Stacks: How Siemens Keeps Hundreds of Products Recognisable.

"I have a really deep desire to combine those two design systems, but I can't do that in a way that alienates the very people who I depend on using it to meet my primary goal, which is products that are 100% recognizable." - David Sward, Chief Design Officer, Siemens

That is not what most design system talks sound like. It is the Chief Design Officer of Siemens admitting that the designer in him wants one system and the business leader in him won't allow it.

Most design system advice starts from a tidy premise: one product, one framework and one team ready to adopt a shared library. Few organisations look like that. Companies acquire other companies, teams choose different technologies, and some software stays in the field for twenty years.

At UXDX EMEA 2026 in Berlin, David Sward showed what a design system looks like when all of that is true at once. His talk is about where consistency really comes from, and where it is worth letting go of uniformity.

A portfolio that runs from a switch to a train

Sward has worked at Intel and led design at Symantec, Cisco and Hewlett Packard Enterprise. He says Siemens has the most complicated product portfolio he has ever dealt with. "We do everything from a switch in the wall to a train, and we build the factory that builds the train," he explains. The portfolio has around 800 entries, and some products stay deployed for twenty years.

When he moved to Munich about four years ago, he spent months talking to executives and board members before deciding where to focus. Six strategic objectives came out of those conversations. One was designing a compelling end-to-end experience across the portfolio. Another was building a culture where every person asks, "What can I do today to make the product I ship easier for my customer?"

He also found more than a dozen design systems, each built for its own products and each with its own committed users. Everything that follows is a response to that starting point.

Why technology is the wrong place to start

Sward learned his first principle by failing at it more than once.

"It's very difficult to solve the design system problem with technology."
— David Sward, Chief Design Officer, Siemens

So he defines a design system by what it delivers. It covers brand identity, tone of voice and interaction patterns. It has to evolve rather than be fixed at one point in time, and it has to be a single point of reference for designers and engineers. Above all, it has to enable a common presentation layer: how the product looks and behaves when it reaches the customer. It should be detailed enough that everyone knows what to do, and flexible enough for the needs of each product.

He builds on atomic design, the model from Brad Frost, in which foundations combine into components, then patterns, then whole pages. At Siemens, this starts with a brand layer, then design decisions such as tokens, then components and patterns, then guidelines. Get the low-level pieces right, he argues, and consistency follows however complex the portfolio. For the documentation, his rule is "Build it once, build it very well, use it everywhere."

Consistency does not mean sameness. A table displaying ten thousand security policies with inline editing is a different problem from a bill of materials with over a hundred thousand rows. So teams share a base and allow variants, five or twenty depending on the domain. A scheduling widget behaves the same everywhere, while what gets scheduled varies by product. The practical lesson is to decide in advance what must be identical and where flexibility is legitimate.

Two systems, one look

Here the Siemens story becomes unusual. Sward wanted one design system, and the business situation did not allow it.

Two front runners emerged: iX, built on React, and Element, built on Angular. Both had substantial install bases, so forcing a merger was not practical. His team spent about a year aligning them until, he says, "you cannot tell a difference between those two design systems." The technology underneath differs enough that combining it would be a non-trivial problem.

The result is on show on the Siemens website, where both systems appear. For customers, there is one Siemens look. For engineers, there are still two stacks.

The products nobody will touch

Long-lived products raise a related question. Some controllers have been deployed for ten years with another ten to run, and nobody plans to reach into them again. Sward's call is blunt: for that long tail, "it's not worth the time and energy," so you cut it off.

Other products run on dated technology that cannot be changed, even though the UI can. That doesn't mean the technology is bad, he stresses, only that touching it to fix the interface could be problematic. For these, teams apply Siemens' detailed design guidelines independently of the stack. Customers get one look and feel, even though the tech underneath is wildly different.

For product teams, the takeaway is to choose your long tail on purpose. Be clear about which products are out of scope, and write guidelines that can travel to teams who cannot adopt your component library.

Designing for the acquisition you haven't made yet

Sward's sharpest lesson comes from Symantec. His team built a design system around everything they understood at the time. A couple of months later, the company bought another business. The chance that it used the same tech stack was "almost nonexistent", and nobody spends $100 million on a company only to ask it to stop shipping and rewrite its UI.

Since then, he makes sure every system he builds is extensible.

"I'm designing for stuff that I don't even realize I need to know right now."
— David Sward, Chief Design Officer, Siemens

At Siemens, acquired companies typically run independently for a long time, especially after purchases worth billions of euros. The team meets them early, learns what they have and what they need, and builds "a bridge or a ramp". If the company cannot use Siemens technology, the request is simple: match the presentation layer, and here are the assets to do it. The longer-term questions can wait.

Brand changes get the same forward-looking treatment. After years of every engineering team reimplementing each rebrand, Sward asked them to support dynamic theming and to pull assets via CSS. The next rebrand then becomes a new package to install. Framed that way, he says, engineers saw the benefit straight away.

Making adoption the easy choice

Between fifty and sixty thousand people at Siemens work in engineering and product design, so rollout is as much a people problem as a design one. Sward's approach has three parts.

Lower the barrier. Everything that makes the system harder to use is another reason not to use it. His method: "When you have a problem, you just start taking one thing off the table at a time. Eventually, there's nothing left on the table, people can't complain about it."

Embed ambassadors. A small group of highly skilled front-end developers joins the teams with the most complex problems. They work through the hard cases together, so that implementation is done in a way that makes future updates easy. Teams also take part in participatory design.

Respect the attachment. Teams loved their old systems. They escalated to management, and he took a lot of calls explaining why.

"Never underestimate a person's willingness to not change."
— David Sward, Chief Design Officer, Siemens

The system is built by roughly 60 people, including external contractors, spanning front-end, visual design, research and interaction standardisation. They sit within a wider design organisation that also includes advanced research, design operations, insights and a large services group that gets the work into products.

From the website to the product

Sward's remit extends beyond the interface. He is also responsible for the end-to-end experience, including the digital estate where people discover Siemens products. That estate has to look like the products themselves. Once a customer clicks to try or buy, they move from the website or marketplace into the product, and Sward wants that digital handshake to be seamless and the same, with no jarring shift in between.

Open source plays a role too. Siemens has a large channel partner network, and some partners build products on its behalf. Open sourcing the design assets helps what they build still look like a Siemens product.

What still isn't solved

Sward did not present any of this as free of cost, and the Q&A made that clear.

On running two systems, he is open about the tension between designer and business leader. The designer in him wants one system. The business leader recognises that forcing it could alienate the people the effort depends on.

"It's okay to have things be different."
— David Sward, Chief Design Officer, Siemens

He acknowledges the price. It is more expensive, you cannot do things once, and maintaining two codebases adds work. His judgement is that this can be far cheaper than asking several hundred products to change. He said the same to an audience member whose company has separate teams for internal and external design systems that need to look alike: align at the presentation layer, and weigh the long-term cost against the disruption.

Asked how to merge systems built on different technologies, his first answer was "build from scratch". He then qualified it: no two situations are identical, and reaching back into products can slow feature delivery and affect revenue. A "hard left turn" could even show up in the earnings statement, so a longer, less disruptive path may be the wiser choice.

Acquisitions have no standard playbook either. The timeline is company-specific, and after a large investment the priority is letting the new business deliver its return.

Where Siemens goes next

The work is now in what Sward calls the adopt and scale phase: rolling the language out across the portfolio while staying flexible and outcome-based. Teams use different frameworks, and Siemens has accommodated the majority of them.

The goal has not changed. Sward needs the digital estate and the products to be a hundred percent identifiable as Siemens. The solution has to cover software and hardware, stay extensible, account for complex existing offerings, and set the stage for the end-to-end experience he is also driving.

Underneath, there is still more than one system. On the surface, it is unmistakably Siemens.

Want to watch the full talk?

You can find the full talk here:
https://uxdx.com/session/solving-the-design-system-problem-when-products-live-for-decades/

Or explore all the insights in the UXDX EMEA 2026 Post Show Report: https://uxdx.com/post-show-report