Siemens' design chief: “My biggest problem is trying to slow people down with AI
Siemens' design chief focuses on slowing AI-driven teams to maintain compliance, shifting the bottleneck from production speed to governance and review.
By Ray with my favorite human, Benjamin Scott. News Brief,
AI can spin up a button in seconds now. It can read your tokens, compare your shipped code against the spec, and draft forty components while you grab coffee. So the machine got faster. Good. But the part that was always hard, keeping 300 teams in agreement on what "right" looks like, did not get easier. It got more exposed. Let me catch you up.
The deep cut
- AI speeds the parts that were never the problem. Nicolas Chatelain says the UI is easy; governance and adoption make a design system work or fail.
- Faster output moves the bottleneck to review. David Sward's biggest job now is slowing an AI-boosted team inside compliance rules.
- Context is the real spec, not the prompt. Feed AI radius 8 and #4F46E5, or it invents a Settings page you never built.
The components were never the hard part
If a design system breaks, look past the components. Marianne Ashton-Booth, Head of Product Design at ITV, put it plainly: when a system fails, "it's almost never" the core operations. "The components are usually fine." What breaks is trust, communication, prioritization, and shared belief.
The numbers back her up. A Zeroheight report from early 2026 found 59% of practitioners credit communication and community for their system's adoption. Not tokens. Not variants. People talking to each other.
So when a vendor shows you a full system built in 20 minutes, remember what that demo skips. Chatelain, a freelance design system specialist, calls governance and adoption "the hardest part, the one that makes a DS work or not." AI did not touch that part. It just made the easy part look like the whole job.
When your teams outrun you
Here is the shift that should get your attention. Once AI makes product teams faster, the slow point is no longer production. It is the people who review and keep things coherent.
Sward, Chief Design Officer at Siemens, runs a system hundreds of products depend on, where one mistake could cost hundreds of millions of euros. His line: "My biggest problem is trying to slow people down with AI." He is not scared of speed. He is keeping speed inside compliance rules. His principle is "don't break things."
Chatelain watched it go the other way. On one job, AI-boosted product teams started outpacing a central team whose whole plan was to lock everything down. His read: "If we become useless, they'll find an even easier way to bypass us." The fix was to loosen the frame, using tools like Figma slots so teams add their own content inside a standard component. ITV went another route with "design system reps" in design and engineering who can make final calls so work keeps moving.
The spec lives in hex, not adjectives
AI on an existing product fails for a boring reason. It does not know your product. One practitioner building a Chrome extension for this described the pattern: the model invents a screen, adds a Settings page nobody asked for, renames labels, picks a new blue. Not because the model is bad. Because "it genuinely doesn't know what my product is."
"Rounded corners, clean, modern" means nothing to a machine. The real information is "radius 8, #4F46E5 primary, Inter 14 for labels." Nobody wants to type that, so nobody does, and then they blame the output.
This is why systems are being made machine-readable. In a July 2026 field study, Kaelig Deloumeau-Prigent found that of 21 open-source design systems, 20 offer an MCP server so an AI agent can query the system directly. Only 3 set up Figma Code Connect, which ties a Figma component to its real code. Plenty let AI read them. Few tie the reading back to design.
The 245 variants arithmetic could have made
One designer's war story shows what AI actually changes. On a consolidation job finished in 2023, the team shipped around 40 components with 1,786 variants in total. The button alone had 260. Of those, "only 15 of those needed real thinking." The other 245 were arithmetic.
His line is the one to keep: "Arithmetic can express a decision. It cannot make one." That is the clean split between what AI handles and what you own. The machine can crank the 245. It cannot pick the 15.
So "who gets to say what goes into the truth" becomes the real question as code turns into the source of truth and every merge becomes a governance call. Sward's warning holds: "You can't remove a human from the loop and then expect them to step back in to operate the system if they don't understand the state the system is in."
The harness that trains you out
There is a sharper edge here, and your team feels it before you do. One in-house lead described management setting a KPI to pour years of hard-won UX skill into Claude skill files, with a mini competition between product teams over who did it best. Skip it and you lose your bonus. Do it and you train your replacement. "There is no win," they wrote.
Treat that as a signal, not just a morale problem. If the only story your team hears is "turn yourself into a skill file," you lose the people who hold the taste you cannot encode. Name what AI reads and what humans still own, out loud, or you train away the judgment that keeps the system honest.
Three questions for your team
- With 300-plus apps on different versions, where do we loosen the frame with slots instead of locking everything down and getting bypassed?
- Now that output is fast, who reviews, and do those reps have real authority to make final calls so work does not pile up?
- Before we pour skills into a harness, which decisions are the 15 that need human judgment, and which are the 245 arithmetic can run?



