“Design, Prototype, Build”
The guidelines site was the single source of truth — tokens, components, patterns and documented behaviours. Teams on .NET, AngularJS, Angular, React and Bootstrap each implemented the same spec in their own stack.
150+ products, accumulated through acquisition, with no shared visual language and no shared implementation. The suite looked and behaved like products from different companies — because it was.
Engineering ran on five different stacks. Several teams had independently adopted Material Design v2 as a reference — but without governance, the same spec produced different results in different products.
five stacks — no single component library spans them
The structural decision: make the system agnostic to any one technology. Not a React library — a specification of tokens, guidelines, patterns and behaviours each team implements in their own stack. Authority in the spec, not the code.
A spec-first system that works across five tech stacks is already platform-agnostic by necessity — adding AI tools as a sixth consumer is an extension, not a reinvention.
Material Design was built for consumer apps. AVEVA's products are operational software — engineers and operators in high-stakes, industrial environments. I governed the Material foundation and added a documented extension layer for what it didn't cover:
- Alarm states and operational status indicators
- High-density data displays for control-room contexts
- Safety-critical interaction and visual conventions
The layer said clearly which patterns were Material-standard and which were AVEVA-specific — so teams knew what they were working with, and why.
Asking 150+ products to hit full compliance at once wasn't realistic. Teams worked through defined tiers at a pace their delivery schedule could absorb — every team showing measurable progress, none blocked by a single deadline. Progress was tracked at programme level in Azure DevOps.
Published, measurable compliance
The adoption levels were documented and split for browser-based and desktop/native applications — so every team knew the next tier to reach, and each product's progress could be tracked at programme level.
The system started as a UX initiative with no dedicated engineering resource. I made the case for a permanent design system engineer to own the implementation infrastructure and bridge spec to code. The role was approved and filled; a dedicated QA resource followed.
The design system moved from a project with UX ownership to a cross-functional team with its own delivery capacity — the organisational foundation that sustained it at scale.
demonstrates
Leading a board-mandated initiative inside a 20-person UX org.
Programme-scale structural thinking: spec-first made the system buildable at all.
Extending a general-purpose system for the demands of industrial software.
Making the case for investment — turning an initiative into a funded team.
