POC Design systems · AI workflow · 2026

A design system that reads its own metrics.

Most AI design tools wait for a prompt. This one starts a step earlier: it watches the business numbers, and when one slips, it helps the designer diagnose why in UX terms, then turns that judgement into a design-system-scoped prompt an AI tool can build, consistently, and measured end to end.

Type
POC
Role
Concept, framework, design, build
Domain
Live commerce (seller)
Built with
Design tokens · HTML/JS · AI tooling
The gap

AI can generate a screen. It can't tell you which screen the data needs.

The current generation of AI design tools (Figma Make, First Draft, Cursor) is genuinely good at turning a written prompt into a screen. But two things are still left entirely to the person: knowing what to change and why, and keeping every generated screen consistent with the rest of the product. Ask ten designers to prompt the same fix and you get ten different screens.

After twenty years building design systems and governance (from LG's UX Lab to Samsung Card), the interesting problem to me isn't "can AI draw the button." It's this: the senior judgement that decides which button, why, and within which system is exactly the part that never gets written down. So I tried to write it down, as a working system.

What breaks today

Three gaps between a metric and a fix.

gap 01

Prompt-driven, not data-driven

Tools react to what a person types. Deciding the screen needs changing at all still depends on someone noticing a number moved.

gap 02

Cause is skipped

"Conversion is low" has many causes: urgency, social proof, choice overload. Jumping straight to a pattern skips the diagnosis that makes it the right pattern.

gap 03

Consistency erodes

Each AI generation is a fresh guess. Without the design system in the loop, screens drift apart and the system decays.

The idea

A closed loop, with the designer in the middle.

The system keeps the design system stable and uses AI to move between the numbers and the screen. It doesn't replace the designer: it front-loads the monitoring and the boilerplate, and hands the judgement calls back at exactly the right moments.

The operating loop
1
Monitor
Track the stream's own baseline for each business metric.
2
Diagnose
A metric slips → propose UX-theory causes. The designer picks, or adds their own.
3
Direct & prompt
Choose how to express the fix → the system writes a token-scoped prompt.
4
Generate
An AI tool builds the screen from the prompt, using design-system tokens.
5
Track
Re-measure the metric that caused it. If it holds, promote the pattern.
The design system stays fixed. AI does the moving; the designer does the deciding.
The framework

Where business data meets the interface, across the funnel.

A product is an ecosystem. Each stage of the funnel throws off its own business data, and each maps to a moment in the experience that a designer can shape. The framework lays that out end to end: for every stage, which data to watch, which UX principles could explain it, and which design-system components are legitimate responses.

business data→ UX principle→ system component
The design system in the loop

Every response is assembled from named tokens.

The framework only works because the responses aren't improvised. Each pattern is built from a small, governed set of tokens and components, the same ones the AI tool is told to use. That's what keeps a fix for one metric from breaking the look of everything around it.

Live-commerce UI kit · excerpt
A governed kit the system draws from
Every pattern the framework proposes resolves to these tokens and components. Named states and colours are what let an AI tool generate a fix that lands inside the system, not beside it.
button/primary · states
default
container Blue_600
text White
emphasis
container Live_500
text White
done
container Bluegray_150
text Bluegray_800
disabled
container Bluegray_100
text Bluegray_400
color/*
live_500
good_500
blue_600
ink_900
warn_500
bluegray_100
badge · toast
Live price · 02:59 42% off Only 12 left
Jimin just bought this
type & space
Aa Display · 22 / 650
Aa Body · 14 / 500
12 Price · tabular 750
48121624
component library · zones
Buy bar
product · price · CTA
buybar/* · button/primary
Purchase toast
real-time social proof
toast/purchase
Scarcity banner
stock · countdown
banner/scarcity · badge/timer
Recommend drawer
in-stream products
drawer/recommend · card/mini
When the system writes a prompt it names these explicitly: button/primary, badge/timer, toast/purchase, and their states, so whatever the AI tool generates inherits the same colours, spacing, and behaviour as the rest of the product.
Why the diagnosis step matters

The same low number can need three different screens.

If view-to-purchase conversion drops, the lazy move is to make the buy button bigger. But conversion can fall because there's no urgency, because buyers can't see social proof, or because the action simply doesn't stand out. Each cause points to a different design, and only a designer who knows the stream should decide which.

So the system never jumps from number to pattern. It proposes causes drawn from UX principles: Hick's Law, Scarcity, Social Proof, Von Restorff, Jakob's Law, and the designer selects, combines, or writes in one the system didn't suggest. Then, for the chosen cause, it offers directions for how to express it, and again leaves room for the designer's own idea. Judgement stays human at every branch.

Sense of UrgencySocial ProofHick's Law Von Restorff EffectParadox of ChoiceValidation & Feedback+ your own
From judgement to prompt

The output is a prompt scoped to the design system.

Once the cause and direction are set, the system assembles a prompt carrying the diagnosis, the direction, and the exact design tokens to use, the constraints that AI tools need but people usually leave out. It targets whichever tool the team uses: Claude Code, Figma Make, or Cursor. Because the tokens are named, the generated screen stays consistent with everything else.

Goal: Improve view→purchase CVR (below 1.20% target) on a live-commerce buy bar. Diagnosed cause: Sense of Urgency; Social Proof. Design direction: live-price countdown, real-time purchase alerts. Use system tokens: badge/timer, toast/purchase, color/live. Consistency: reuse live-UI spacing & type tokens; keep one primary action; non-blocking. Measure: view→purchase CVR, buy-button tap rate. Output for: Claude Code.

The prototype makes this whole path live. Move a metric, diagnose it, and the seller screen rebuilds with only the patterns your diagnosis called for, then an impact panel shows the metric being re-measured and the pattern promoted if it holds.

What it's really arguing

A point of view on the designer's role in the AI era.

Data starts the work

The trigger is a business signal, not a prompt. Design begins where the numbers move.

Judgement is the scarce part

AI can generate; it can't diagnose intent. The cause-and-direction step keeps the senior call human.

The system is the guardrail

Every generation is scoped to named tokens, so speed never costs consistency.

Nothing ships unmeasured

The metric that triggered the change is the metric that judges it. Patterns earn their place.

Close

Semi-automated, deliberately.

The goal was never a machine that designs on its own. It's a system that does the watching and the wiring, and asks the designer to do the one thing only they can: decide what the experience should mean, and why. That's the version of AI-era design work I want to do, and this is me building it, not just talking about it.