How Design Became the Engineering Layer

Years of building functionality first had left the admin platform deeply inconsistent: old styles next to new ones, identical components looking different across pages, interaction patterns varying for no reason. Not one broken thing, hundreds of small decisions made independently over years, with nothing connecting them.

Every UI improvement meant writing PHP views, custom SCSS, and jQuery by hand. Modern patterns were possible in theory. In practice, the effort required made them disappear from roadmap conversations before they started. The chaos had been there long enough to feel normal.

I'd been using Claude Code in my design work for a while, gradually shifting from prototyping tool to something more structural. The conversation that started this happened in the office. I was complaining about the state of Control's admin UI to Amit, a developer equally frustrated from the engineering side.

He said the generation problem might be more automatable than it looked. I said I wanted to try. We didn't ask for permission, we just started, not on the roadmap, not scheduled, built in parallel with normal work because it needed doing.

Since I had no repository access, I used Claude Code to scrape the live Control platform and generate a structured inventory of every UI pattern across all 120 pages. Underneath the visual inconsistency, the interaction patterns were more coherent than they looked — the chaos was mostly CSS and layout, not structure. That meant mapping to an existing component system was possible.

Amit built the architecture that connected the component library to the live platform: a React islands model, self-contained React apps embedded directly into the existing PHP/Twig pages via Vite. The PHP backend handles routing, sessions, and data as before. No migration. No rewrite.

With a well-documented, typed component library in place, Claude Code can generate a complete screen from a prototype or description: React component, TypeScript data layer, PHP controller, routing, and navigation, ready to deploy. What previously took days of PHP template work now happens in a single session, because the design system gives the model something consistent enough to generate from.

We were deliberate about the order. Allies first: my manager and the design team, people who would engage constructively and sharpen the pitch. Engineering leads next, where Amit's credibility as a developer from the inside removed every objection I couldn't answer alone. By the time we reached product stakeholders, the demo had already built its own momentum.

We never led with the technology. We led with the problem. Everyone in that room had looked at Control and wished it was better. The demo didn't need explaining, it just needed to run. That momentum carried through to a formal sign-off across product, engineering, and design leadership.

With approval in place, I mapped all 120 Control pages into page types, manually, page by page, since no documentation existed. Nine templates emerged covering the full surface area. Once built and validated, any page can be regenerated by dropping it into the right template and running it through the workflow.

The sequencing was deliberate: start old and low-traffic, validate without risk, deprecate legacy code, build team confidence. High-traffic pages come next, once production quality is proven. The worst thing that could happen to this initiative was shipping something broken on a page thousands of people use every day.

Once approval came through, FE developers were brought into the workflow. Their job shifted: instead of receiving Figma specs and building their own interpretation, they now receive working code generated directly from the design system and refine it for production. The gap between design intent and deployed output closed almost entirely.

In parallel, we're optimizing the skills/md files, the instruction layer that tells Claude Code exactly how to use the component library and what patterns to follow. Better-calibrated skills mean more consistent output from the first pass and fewer revision rounds. The goal isn't just to generate screens faster. It's to make generation reliable enough that FE review becomes a quality check, not a rebuild.

Control is no longer the only platform running this workflow. The same audit-to-template methodology is now being applied to Gainsight's Education platform and Analytics platform — both actively in progress, not planned future work.

This is the part of the story that emerged after initial adoption: what started as two people frustrated enough to try something without being asked has become organisational infrastructure, with formal sign-off and a growing list of platforms depending on it.

The easy read on this project is that it's about AI tooling. The more important thing it demonstrated: when design and engineering don't have a common foundation, every screen is a negotiation. The design system solved that, not by replacing engineers, but by giving Claude Code something consistent enough to generate from and developers something reliable enough to ship from.

This started because two people were frustrated enough to try something without being asked. A lot of problems that accumulate in legacy products sit outside anyone's formal remit. Waiting for this to appear on a roadmap would have meant waiting indefinitely.

No PM. No brief. No roadmap item. We created the mandate.