Design systems that designers, engineers, and AI tools all follow

At Sygnum there were nine different design styles across separate CSS repositories. At Workwise, early decisions had stopped scaling. At Aerospike, multiple teams were about to start building without anything shared to build from.

The pattern was the same every time: inconsistent UI across teams, multiple versions of the same component, local decisions without shared standards, new people not knowing what good looked like. It wasn't that there weren't components. It was that nobody agreed on them.

Across all three projects, I owned the design system from definition through adoption. At Sygnum and Aerospike, I was the first designer hired and defined standards from scratch, working directly with front-end engineers. At Workwise, I stabilised and evolved a system that had grown organically.

In all cases, I defined system architecture with engineering input, owned design decisions and contribution rules, and partnered closely with front-end engineers day-to-day.

At Sygnum, the biggest challenge was convincing engineering teams to commit time to migrating away from their own hardcoded components into the monorepo. Every team had built their own things and regarded those things as working. Getting them to agree that consolidating was worth the disruption required making the case repeatedly, not just once.

At Workwise the resistance was more passive. Nobody was opposed to the design system. They just didn't think it was important enough to give me frontend time to make updates. That pattern repeated across all three companies in different forms: the technical work in a design system is the tractable part. Getting people to treat it as real work, rather than a design team side project, is the actual job.

Building components was the easy bit. The harder part was aligning design intent in Figma with production reality in code, and figuring out how decisions actually get made across people and process.

At Aerospike there was a fourth challenge none of us had dealt with before: AI tools were generating UI and prototypes alongside the team. A system designed for humans wasn't legible to machines. That had to change too.

At Sygnum and Aerospike, I based the system on Material UI: a deliberate tradeoff for accessibility defaults, proven interaction patterns, and faster alignment with engineering. We adapted the visual layer to match the product instead of rebuilding everything from scratch.

I focused on the parts that created the most friction between teams: tokens as the foundation (colour, typography, spacing, layout — defined once, mapped between design and code), components with clear states and behaviours built with accessibility from the start, contribution rules that made it clear how the system evolved, and documentation that explained decisions — not just what to use, but why it existed and when.

At Aerospike, I extended the documentation into a structured markdown layer that defines tokens and their purpose, component usage and constraints, design principles with reasoning, and contribution logic. This became a shared instruction layer that Claude, Cursor, and Codex can use to generate system-aligned output.

The system evolved from a set of assets into a loop: Figma captures design intent → code holds production components → the markdown layer defines system logic and guidance → AI tools generate UI using those rules.

Decisions get encoded once and reused across every layer. That speeds things up, but it also means inconsistency scales fast when rules aren't clear. That's what the contribution rules and review process manage.

Across all three systems, components were reused consistently, design and engineering rework went down, and the systems stayed in place beyond my involvement. Stakeholders gained confidence in UI decisions and delivery became more predictable.

None of these were perfect systems. They were solid enough that teams kept using them and building on top of them without needing to start over. That's what I was aiming for.

Design systems need maintenance, conversation, and evolution. The work doesn't stop at launch. It just becomes a different kind of work.

What I find interesting now is that the surface area is changing. Systems aren't just component libraries anymore. They're becoming the shared language between design, engineering, and the AI tools building alongside the team. Keeping that consistent across all three is a harder and more interesting version of the same problem. That's the work I'm most interested in.

The hardest part of every system I've built wasn't the components or the architecture or the documentation. It was convincing people the work was real. Engineers have features to ship. Migrating hardcoded components to a shared library doesn't feel urgent until it does. You end up making the case continuously rather than once.

The systems I'm most proud of are the ones where I convinced engineers who didn't initially see the value. That meant showing the work in terms they cared about, making the benefits visible in their day-to-day rather than just in design reviews. Once they got it, they started making the case to their own teammates. Those conversations spread further than any documentation I wrote.

That argument has a new audience now. AI tools consume design systems the same way engineers do. If the people on the team don't follow the system, the tools won't either. It's the same argument, to a bigger room.