Mandala case study: Human-governed, AI-powered

Mandala is a rebuild of a system that is already implemented, already shipped, and already relied on by multiple teams across two brands, every day, so replacing it wholesale was never realistic. I am building the replacement inside a private working environment, a complete copy of the existing libraries, visible only to me, my closest team and Claude, so that the libraries in daily use stay untouched until Mandala has genuinely earned the right to replace them.

Working this way surfaced a great deal of history nobody had been tracking. Two colour libraries had ended up sharing the same name, so a single component could be pulling its colour from either one depending on which happened to be open the day someone built it, one screen rendering teal on one binding and blue on another, at the same time, for what was meant to be the same semantic colour. Thousands of stray bindings had built up over years with no record of why, and a number of components had quietly gone orphaned inside the old structure. None of it ever reached a real product, because a private working copy has no real consumers until it has earned them. The closest this project has come to a genuine scare was a deprecated library published by accident rather than deleted, tens of thousands of bindings suddenly loose with no way to tell from inside Figma who might already be relying on it. The fear lasted about as long as it took to remember the architecture: a private file, by construction, has no consumers to break.

That became one of the operating principles of the whole project: a design system is not only a set of components, it is an accumulated set of decisions and dependencies, and those have to be understood before they can be safely redesigned.

The most important part of Mandala is the governance model that decides how the library gets built, not the component library itself.

Left without a written instruction, an AI collaborator does not wait. It improvises, fills the gap with its own best guess, and does so with complete confidence, often producing something that looks entirely plausible while quietly breaking an assumption elsewhere in the system that nobody has checked, and the discipline in this project has never been trusting Claude to know when to stop, it has been never leaving a gap for it to fill in the first place, and everything else here follows from that one decision.

Before Claude touched a single component, I wrote the rules it would work inside: a project rulebook that every session inherits, rewritten again and again as new edge cases surfaced; a dedicated accessibility rulebook, built out of my own training and years of practice, that runs every check a machine can genuinely be trusted to run and sets out the exact manual test for everything it cannot; a numbered, dated decision log, so that a question already settled cannot be reopened or changed without a name and a reason attached to the change; and a set of custom skills, all built in house, that encode how every component gets designed, built, exported and audited. Nothing is called finished until it clears three separate gates, the code itself, a full manual walkthrough with a keyboard and two screen readers, and a final sign-off against every decision already on record, and nothing is committed, deployed or published without my explicit approval, every single time.

That discipline gets tested in small ways, constantly. A gap in the icon library once turned out to be nothing of the sort, what looked like a missing component was a stale, cached read of an old node sitting under a key that had long since been repointed to something else entirely, and neither a node ID nor a variant name turned out to be safe to treat as identity on its own. The decision log exists for exactly this kind of moment, and it has also, at least once, caught the two of us wrong together rather than Claude wrong alone, which is the clearest proof I have that it is not a formality.

The result is a collaborator that rarely gets things wrong, and when it does, the gates catch it before it reaches anything that matters, because the speed is Claude's job and the judgement stays mine, and neither of us ever has to simply trust the other to get it right.

Colour is the foundation that took the longest and taught the most, because it could not be built the way colour systems normally are. Most start with a primitive scale and give it meaning afterwards. Mandala already had its semantic tokens in place, roles like primary, danger and warning, before it had a primitive colour scale underneath them, so the primitives had to be built backwards to fit decisions that already existed. The result is eighteen colour themes, every one WCAG AA accessible, letting a person personalise the interface to their own eyes rather than settle for whichever palette a product happened to ship with, across illustrations, charts and every primary action alike. The private, occasionally hair-raising process of getting there has its own full account in a companion piece.

The same discipline applied when the type scale had to travel into Japanese, Chinese and Korean. Latin-script languages occupy space on a screen in a completely different way from these three scripts, which is exactly why an automated approach did not work, internationalisation here needed a human hand and a human eye, tested screen by screen against real, dense BigFix layouts rather than guessed at from a specimen sheet, and it landed in a different place for each language on purpose, because a rule applied uniformly to three scripts that happen to share a region on a map is not the same thing as a rule that was actually tested. The full story, including where the three languages agreed and where they did not, is its own piece.

The foundations are completely tokenised. Colour, typography, spacing and the rest are defined once as tokens, which keeps the system consistent and makes it readable by AI as well as by people. Every foundation is shipped and exported through the same pipeline, downloadable as CSS and JSON, and sits behind a gate that stands permanently between any future change and the published site.

Icons and illustrations are built on the same idea. I have shipped 180 icons, each one a component that points at a path, so no icon has to be exported in several colours: the path simply picks up the colour of its container, which keeps the code lighter and easier to maintain. The (current) 60+ illustrations work the same way. They are paths too, and each one adapts to the colour theme, picking up the primary colour of the team using it and personalising part of the illustration in that colour.

Components draw on all of this. They move through the same governance one at a time, each held to the full standard rather than shortcut through it, and every one ships in React, the framework the teams use, so a team reaching for Mandala does not need to reverse-engineer it.

What this proves is not that an AI can be handed a design system and left to get on with it, but the opposite: held inside rules a design team actually wrote, checked by gates a human signs off by hand, and never left to guess at a decision it was not given, an AI collaborator can carry an enormous amount of the labour without ever carrying the judgement.

Nearly two decades of design and accessibility practice sit behind every rule, gate and decision that governs Mandala, and AI gives that experience more reach rather than replacing it, so the judgement stays human and the busy-work goes to AI, human-governed and AI-powered by design, and the quality is never the thing that gets traded away to get there.