Design Systems, Content & Ops in the AI Era

Dan is a staff designer, twelve years in, at a US product company whose engineers discovered prompt-to-UI six months ago. They generate screens from Cursor with the Figma MCP server attached, and velocity is genuinely up. So is something else. In Monday's design review Dan counts four buttons that are not the design-system button — same blue, slightly different radius, hand-rolled hover state, no pressed state at all. A settings page uses a card component that looks like Card/Elevated but is a generated look-alike with hardcoded hex values. The spacing is 14px in a system built on an 8-point grid.

None of this is malicious. The model did its best with what it could read — and Dan's design system, it turns out, is nearly unreadable to a machine. Components named Component 47 and btn_final_v2. Colors applied as raw hex instead of bound variables. No published exemplars showing correct composition. No written rules saying "never hand-roll a button." The system was built as a reference for humans who already know the conventions — and its new highest-volume consumer has never attended a crit.

Dan's instinct is to police harder: catch violations in review, file tickets, repeat. That loses, arithmetically — the model generates faster than he can review. The move that wins is upstream: make the system itself the context the machine consumes, so generation lands on-system by default and review catches exceptions instead of everything.

The stewardship flip

For fifteen years, design-system quality meant serving human consumers: findable components, readable docs, sensible onboarding. Every one of those investments now has a second, stricter customer. Machines don't infer conventions from hallway knowledge; they read exactly what's in the file. The supply chain for on-system AI generation has four parts:

• Semantic, consistent namingButton/Primary/Large, not Frame 892. A model choosing components navigates by name; ambiguity in equals ambiguity out.
• Bound variables everywhereevery color, spacing, radius, and type value bound to a token, never hardcoded. Tokens are how a generator learns "the blue" is color/action/primary, and how generated output stays themeable.
• Published exemplarscomplete, canonical screens showing components composed correctly: the settings page as it should be built, the form pattern, the empty state. Models imitate examples far more reliably than they follow abstractions.
• Written generation rulesa plain-language rules file that travels with the system: "always use DS components, never hand-roll equivalents; spacing on the 8-pt scale only; every screen includes empty/loading/error states; interactive elements meet 44px targets." This is the design-side supply for engineering's instruction files and MCP grounding.

The same preparation pays a second dividend at handoff: MCP-ready files. When engineering's agents pull your frames through the Figma MCP server, they read the layer tree, variables, and component references — nothing else. Everything the file doesn't say, the agent invents. The readiness checklist follows directly: auto-layout everywhere (absolute positioning reads as noise), every value bound to a variable (a hardcoded hex forces the agent to guess which token you meant), components named semantically and used from the library (a detached instance loses its provenance and becomes anonymous rectangles), and intent annotations on anything a layer tree can't express — edge-case behavior, conditional logic, "this list virtualizes past 50 items." The quality bar has a memorable measure: how little the consuming agent hallucinates. Before-and-after tests make it vivid — the same screen pulled through MCP from a messy file and a prepared one produce implementations that differ not by polish but by correctness, and Lab 8's messy-library exercise is exactly this experiment run on your own hands.

Lab 8 is this flip end to end: you receive a deliberately messy library, restructure it, write the rules file, and prove the work by prompting a new screen that lands on-system — real DS components, not look-alikes.

Auditing drift, reviewing generated UI

Restructuring starts with knowing how bad it is. A drift audit — the Figma agent plus library analytics, or a purpose-built plugin — sweeps libraries and product files for off-token colors, spacing, and type; detached instances; and near-duplicate components. The output is a prioritized consolidation plan, each item with evidence links to the offending frames.

Downstream of the audit sits the ongoing gate: reviewing AI-generated UI for system compliance. Whether the UI arrives as an engineer's PR screenshot or a teammate's Make prototype, the designer-side checklist is stable:

The critical habit: every violation you catch feeds back into the generation rules. A look-alike button in review means the rules file gains a line, the exemplar gets more prominent, or a token gets renamed for clarity. Review without feedback is Dan's losing arithmetic; review that hardens the rules converges.

Documentation and the voice-system engine

Two generation workflows make the system's human-facing half cheaper to maintain.

Component docs with AI. Usage guidelines, do/don't pairs, and accessibility notes can be drafted from a component's own anatomy — its variants, properties, and exemplar usage. Feed the model the component's actual structure and two screens of correct use, and it produces a serviceable first draft: when to use it, when to reach for the alternative, which variant fits which density, what the keyboard behavior should be. The draft is competent and generic; your edit supplies voice and the judgment calls the anatomy can't reveal — "don't nest Elevated cards inside modals; the double elevation reads as a rendering bug," the kind of line only someone who has watched the misuse can write. Published to the DS site, refreshed when the component changes, and — because documentation is now machine-read context too — written in declarative rules a generator can follow, not just prose a human can nod along to.

The voice-system microcopy engine. Encode your brand voice — principles, tone spectrum, terminology, banned words — as a system prompt, then add few-shot exemplars: eight to twelve real strings your team considers perfect, spanning buttons, errors, empty states, and notifications. That reusable engine generates microcopy in context ("error message, payment failure, user is mid-checkout, tone: calm and concrete"), and a writer edits. Consistency comes from the system; judgment stays human — every generated string gets a keep/edit/rewrite decision, and Lab 9 grades the rationale, not just the copy.

The engine powers content operations at scale:

• Error and empty-state overhaulsinventory every such string across a surface, rewrite against a rubric (plain language, states the cause, names the next action), review in batches with the worst offenders first.
• Terminology-drift sweepscluster all product strings to expose synonym drift (delete/remove/discard), tone outliers, and reading-level spikes; you adjudicate a term base that feeds back into the voice system prompt.
• Localization review in contextdraft translations generated with screenshots and flow context, then design-reviewed for layout breakage and cultural register. The native-speaker gate for target markets stays; AI moved the drudgery, not the accountability.

The accessibility gate

The last stop before handoff is the artifact-side accessibility review — and it is the module's sharpest lesson in tool trust, because it mixes deterministic checks with probabilistic ones and you must never confuse the two.

1. 1Contrast — deterministic tools only. Stark, axe for Designs, or any WCAG contrast checker computes ratios mathematically. Never ask an LLM to eyeball contrast; language models cannot do this and will confidently pretend otherwise.
2. 2Target sizes — measure. Interactive targets at 44px minimum; a plugin or the agent can flag violations; you confirm.
3. 3Focus order — annotate by hand, draft by AI. AI proposes a tab order from the layout; you verify it matches interaction logic and annotate the file so engineering inherits intent, not guesses.
4. 4Heading hierarchy and structureone logical heading tree per screen, annotated for semantics before code exists.
5. 5Alt text — AI drafts, human verifies. Vision models draft serviceable alt text for content imagery; you edit for context and purpose, and mark decorative images as decorative.

Every finding maps to a WCAG criterion in a findings table. Nothing ships on AI's word — the review is yours; the tools just made it fast. Lab 10 runs this gate on a seeded flow and scores you on catching every violation without inventing false positives.

The same vision tooling closes the loop after build: screenshot the shipped product against design frames and let a model draft the discrepancy list — spacing, type, color, missing states — which you triage into engineering tickets. Design QA becomes a sweep you run every release, not a luxury for launch week.

Try it now

1. 1Audit one component. Pick your most-used component and inspect it as a machine would: is the name semantic, are all values token-bound, does a published exemplar show correct use? Fix the worst of the three.
2. 2Draft your generation rules. Write the first five lines of your system's rules file — the five violations you'd most hate to see in generated UI, phrased as instructions a model can follow.
3. 3Build the voice engine, minimally. Encode your product's voice as a system prompt with five exemplar strings, generate three variants of one real error message, and make a keep/edit/rewrite call on each with one line of rationale.