From AI screens to a design system
You used v0, Lovable, or Cursor. Now you have twenty screens. They are not a design system. They are an inventory.
A design system is not a folder of outputs. It is a set of named decisions (tokens, components, states) that your team reuses so the next feature does not invent a fifth button style.
Until you extract and name the patterns, every new screen is a one-off. That is how products drift.
How do I turn AI-built screens into a real product design system?
Extract before you generate more. That is the only order that works.
1. Inventory patterns — list every button, card, form, table, modal, and empty state you already generated. Write them down.
2. Merge near-duplicates — if three screens use three different card treatments for the same job, pick one. Delete the rest. Stop multiplying variants.
3. Name color, type, and spacing tokens — turn `#6366f1` into `--color-primary`. Turn `mt-4` into `--space-md`. Names let you change one value everywhere instead of hunting twenty files.
4. Define empty, loading, error, and edge states — the happy path is 20% of design. The other 80% is what happens when data is missing, the API is slow, permissions deny access, or the user hits a constraint. Design those states on purpose.
5. One source of truth — pick Figma or code. Not both drifting. If Figma is the source, engineers pull from it. If code is the source, Figma documents what shipped. Maintaining two sources that disagree is how systems collapse.
Do that work once. Then generate inside the system. Without extraction, more generation just multiplies the mess.
Why do AI-generated components keep drifting without tokens and states?
Because each prompt invents local values instead of reusing named decisions.
You ask for a signup form. The tool gives you padding, a button, a color. You ask for a settings screen. It gives you different padding, a different button, a different shade of the same color. Both look fine in isolation. Together they read as two products.
The drift is not laziness. It is that the tool has no memory of your system. It optimizes for one screen at a time. You are the system.
Tokens fix this. When you name `--color-primary`, `--space-md`, and `--radius-base`, you can tell the next prompt to use those. The output stays coherent because the constraints are explicit.
States multiply the problem. If you only design the happy path, the AI never learns what empty, loading, or error look like in your product. Every new feature invents its own failure UI. That is why products feel like Frankenstein assemblies instead of systems.
What belongs in a minimum design system before SaaS launch?
Not an enterprise token bible. A working minimum.
Type scale — one set of sizes and weights. Heading levels. Body. Caption. UI labels. That is it. Stop inventing a new text size for every section.
Color — primary, neutral scale, success, warning, error, surface tints. Maybe accent if your brand needs two colors. Skip the twenty-shade palette unless you are already using it. Unused tokens are documentation debt.
Spacing — four to six values that cover tight, base, relaxed, and section gaps. Name them. Use them everywhere. Do not let prompts invent `23px` when `--space-lg` exists.
Primary components — button (primary, secondary, ghost), input, card, table, modal. Build those well. Everything else can wait until you prove you need it.
States those components need — default, hover, focus, active, disabled, loading, error. Not as an afterthought. As the core of the component definition.
That minimum is enough to ship a coherent MVP and stop drift. You can expand it later when real use proves what is missing. Starting with sixty components nobody uses is how design systems become obstacles instead of tools.
When to bring in product design
If extraction and naming are still fuzzy, or if the product is live and drift is already costing you trust, bring in Product Design. That service maps journeys, defines states, and delivers a system that keeps squads coherent after launch.
If your product has agents, chat, or other probabilistic UI, AI Product Design is the better door. Those surfaces need failure-first design (disclosure, undo, recovery) because trust breaks when the model is wrong, not when it is right.
If the core problem is still unclear, or if stakeholders disagree about what to fix first, Strategy & Research might be the right first step. Clarity before craft.
Related reading: Fix AI-built UI that looks wrong, Why AI UI looks the same, Cleanup AI SaaS UI before launch.
Book a call if you want a straight read on what to extract first and what can wait.