AI Direction
The Design System That Uses Itself
The promise at stake: adoption — the gap between "we have a design system" and "I know how to build my screen with it the right way."
Outcome recap
- A working proof that adoption — the hardest design-system problem — can be attacked from a new angle
- One closed loop: build, self-check, and self-improve, instead of three separate tools
- Accessibility scanning and prototype-building share the same machinery
The challenge
The hardest problem in a design system isn't building it. It's adoption. A system only returns its investment when product teams reach for it by default and apply it correctly — and the work that closes the gap between "we have a design system" and "I know how to build my screen with it the right way" is unglamorous and chronically under-resourced. Adoption rarely gets its own budget line. Meanwhile, every team that reinvents a component or misapplies a token quietly erodes the consistency the system exists to guarantee.
The conventional answer is more governance — police usage, review everything. That doesn't scale, and it breeds friction with the very teams you need on your side. I wanted to invert the problem: instead of forcing adoption, make building it right the path of least resistance.
What I did
I made the bet — and built it on my own initiative, rather than waiting for the adoption problem to get funded. The bet: an AI agent that prototypes faithfully to the system. You describe a screen in plain language; it produces a working, on-brand prototype built only from the real components and tokens. It's on-brand by construction, not by approximation, because it consumes the live design system the same way a real product team would.
The important design decision was to make it a closed loop, not a one-shot generator:
- Build — prompt-to-prototype, constrained to the system's real component and token vocabulary, with a brand-expression "grammar" layer above the components — how the brand actually looks in practice: typographic hierarchy, how much color and where, density and breathing room — so the output feels authentic, not assembled.
- Self-check — before any page is allowed to be "done," the agent passes a quality harness: it screenshots its own work at three widths and reviews it against layout and brand rules, and it runs an automated accessibility scan with a zero-serious-violations bar. The agent looks at what it built before declaring it finished — which is what stops AI output from being plausible-but-wrong.
- Self-improve — underneath it all, a machine-readable registry of every component and token, plus living guidance. When a misuse is corrected, the correction persists, so the system gets more accurate and more opinionated with every session.
The kicker: build and audit are one capability. The accessibility scanning baked into the "done" check is the same machinery that produced my WCAG accessibility report. "Build it right" and "prove it's right" aren't two tools; they're one loop. Every prototype the system generates is also a probe of what the design system gets wrong.
I used it as a real working tool, not a demo prop — for example, to turn an ambiguous product spec into a clickable, state-by-state prototype that an internal product team could react to, moving a conversation from a document full of "TBD" to something tangible they could click.
Outcome & impact
A working proof that the hardest design-system problem — adoption — can be attacked from a new angle: make the correct path the easy path instead of policing the wrong ones. Production-looking prototypes from plain-language prompts, on-brand by construction and accessible by default. One loop that both accelerates building and enforces quality, so velocity and rigor stop being a trade-off. A self-improving knowledge base about the system that compounds in value and is positioned to feed future AI tooling. A demonstration of AI fluency at the leadership altitude: directing agentic AI toward a strategic problem, defining the quality bar, and judging the output — the opposite of an engineer hunting for a use case. It's already shaping how the team thinks about where the design system goes next.
Skills demonstrated
- Design-system strategy
- Adoption and DesignOps thinking
- Agentic AI direction
- Prompt-to-prototype system design
- Quality-harness and self-verification design
- Accessibility automation
- Knowledge-substrate (registry) design
- Product prototyping
- Technical judgment at leadership altitude
Proof / artifacts
[Image: Working playground demo — plain-language prompt in, on-brand accessible prototype out — placeholder]
[Image: Closed-loop diagram — build / self-check / self-improve, showing the registry, brand-grammar layer, and verification scripts — placeholder]
[Image: Shared-harness callout — the link showing build and accessibility audit run on the same machinery — placeholder]
[Image: Sample prototype — a multi-state product-journey redesign used for internal team ideation (explicitly an ideation exercise, not a shipped feature) — placeholder]