Extract a Design System Before You Prompt an AI Builder

If you want an AI app builder to produce something that doesn’t look like every other AI-generated app, extract a design system before you write the prompt. Not a mood board, not “clean and premium” — an actual token set: a spacing base, a type-scale ratio, a semantic color table with computed contrast ratios. The difference between a vague style adjective and a measured token is the difference between an instruction the model can drift away from and one you can check against its output.

One boundary up front, in plain terms, because it shapes everything that follows: extract rigour, not identity. A 4px spacing base, a 1.333 type ratio, a 4.5:1 contrast target — these are structural, systemic choices, and measuring them off a site you admire is legitimate. A wordmark, a distinctive illustration style, a brand’s proprietary iconography — that is someone’s identity, and reproducing it is a different act entirely. Courts have been drawing versions of this line for decades, and we cover the actual doctrine in section 07.

This guide walks through the three-tier token taxonomy the industry has converged on, how to read tokens off a live reference site with nothing more exotic than DevTools, the WCAG contrast maths that turns “looks premium” into a passing number, where the extracted brief plugs into v0, Lovable, and Bolt, and the legal framework that separates fair structural learning from imitation.

The intuition behind vague style prompts is that the model has seen Apple’s site, so naming Apple should transfer the look. What actually transfers is a fuzzy average of everything the adjective evokes — and, more importantly, an instruction you have no way to verify. When the output comes back, “does this look like Apple?” is a judgment call. “Is the body text 16px with a 1.5 line-height and does every text/surface pair clear 4.5:1?” is a measurement.

The research on prompt specificity supports exactly this distinction — and it’s worth being precise about what it does and doesn’t show, because the honest version is more useful than the slogan. One study of prompt quality and code-generation outcomes found quality improved as prompts moved from bare requirements toward detailed design documents. A separate study of 265 manually validated developer-ChatGPT interactions drawn from open-source pull requests found specificity — alongside context — most strongly associated with whether the model produced actionable code, while explicit verification cues were the primary predictor of whether that code was actually adopted.

A third strand measured how code-generation accuracy scales with prompt specificity by building, for each task, a partial order of prompts running from minimal to maximally detailed. Sensitivity varied by task, but the qualitative analysis named the drivers plainly: explicit input/output specifications, edge-case handling, and stepwise breakdowns. More detail raised pass rates — and the detail that did the work was the concrete, checkable kind.

Read those three results together and the pattern is not “spec-driven always wins.” It is narrower and more actionable: the detail that moves the numbers is the detail someone could check. A token set is checkable by construction — every value in it is a number a reviewer, or the builder itself, can verify against output. “Make it look like Apple” is not a checkable constraint at all: it gives the model no target and you no test. That second half is our argument rather than a published finding — no study we found pits style adjectives against token briefs inside an app builder — but it follows directly from where the research says specificity pays. That distinction is the entire argument of this post, and it’s the same argument our specification-quality brief method makes for AI output generally.

Design tokens stopped being a house convention and became a standard in October 2025, when the Design Tokens Community Group — a W3C community group — shipped the first stable version of its Design Tokens Format Module, version 2025.10, on October 28, 2025. The spec is backed by more than twenty editors and authors from organizations including Adobe, Amazon, Google, Meta, Microsoft, Salesforce, Shopify, Figma, Sketch, and Framer, and it standardizes exactly the things an extraction brief needs: theming and multi-brand support, modern color spaces like Display P3 and Oklch, token relationships via aliases, and one token file compiling out to iOS, Android, web, and Flutter. Tools including Style Dictionary, Tokens Studio, Terrazzo, Penpot, and Figma implement the format — though implementing a format and defaulting to it in production are different claims, and adoption depth varies by tool. The spec itself lives at designtokens.org.

The architecture that matters for your brief is the three-tier model used across the industry — by Style Dictionary, Shopify Polaris, the U.S. Web Design System, and Contentful’s design system among others. Three tiers, one-way dependencies:

The dependency direction is one-way by design: primitives feed semantics, semantics feed components. Reverse references cause circular-dependency build errors in tools like Style Dictionary — which is useful discipline for a brief too, because it forces you to name why a color exists before you assign it to a button. If you’re building a system from a blank slate rather than extracting one, our companion guide on building the design system from scratch covers the governance side; this post is the extraction companion.

You don’t need special tooling to start. The Computed panel in Chrome or Firefox DevTools shows resolved values for any selected element, including CSS custom properties, and the console gives you direct reads: getComputedStyle(el).getPropertyValue("--color-action-primary") returns any custom property’s resolved value. Inspect the body for the base font size and line-height, headings for the type scale, buttons and cards for radii and shadows, and section wrappers for the spacing rhythm. A whole category of browser extensions and web tools now exists specifically for this — token extractors, CSS-to-Tailwind converters, extract-to-Figma tools — which tells you this is a recognized, tooled workflow rather than a hack. Treat any individual tool’s accuracy claims as vendor-stated; the DevTools read is the ground truth.

Be equally clear about what extraction cannot give you. Computed styles are resolved values — the final hex and pixel numbers — not the authoring intent behind them. The reference site’s real token source of truth, its Figma variables or its internal Style Dictionary config, is invisible from the rendered page. What you extract is a reverse-engineered approximation of the ramp and scale, and you should present it to the builder as exactly that. A single static read also misses hover, focus, and active states, dark-mode variants, and responsive breakpoint changes — some extraction tools claim to auto-capture these, but that’s a per-tool vendor claim, not a property of the method.

Contrast is the clearest example of a taste question that is secretly arithmetic. WCAG defines the contrast ratio as (L1 + 0.05) / (L2 + 0.05), where L1 is the relative luminance of the lighter color and L2 the darker, producing ratios from 1:1 to 21:1. Relative luminance itself is a weighted sum of linearized sRGB channels — roughly 0.2126·R + 0.7152·G + 0.0722·B after each channel is gamma-corrected — which is why green carries roughly an order of magnitude more perceptual weight than blue. The exact linearization constants live in the W3C’s Understanding SC 1.4.3 document; use the source rather than a restated constant.

The practical consequence: because the formula is asymmetric and non-linear, a color ramp cannot be eyeballed into compliance. Two pairs that look similarly distinct can compute to wildly different ratios depending on which channel carries the difference. That’s precisely why an extracted palette belongs in the brief with its computed ratios attached — the builder gets a target it can hit, and you get a check you can run on whatever it generates.

Typography extracts to two numbers. First, the type-scale ratio: divide each heading’s computed font size by the next step down and a well-built site converges on a consistent multiplier. The common ratios are named after musical intervals — 1.25 (major third), 1.333 (perfect fourth), 1.5 (perfect fifth), 1.618 (golden ratio) — with 1.25 commonly described in typography-tool documentation as the most popular choice for restrained hierarchy and 1.333 as a versatile default with more dramatic contrast. Second, line-height: recommended body-text line-height sits at 1.5–1.6× the font size, and WCAG’s own visual-presentation guidance (SC 1.4.8, a AAA criterion widely adopted as best practice at any level) sets 1.5 as the floor for body text.

Elevation is the token category most extraction briefs get wrong. Material Design’s scale runs roughly 1dp to 24dp with each level tied to a functional role — cards, app bars, dialogs — elevation defined semantically, not as arbitrary shadow values. And shadows are a light-mode technology: on a dark surface there’s no meaningful contrast between a dark shadow and a dark background, which is why Material You formalizes dark-mode elevation as tonal elevation — each step a slightly lighter tint of the base surface color rather than a shadow.

This table is the method in one place: what to measure on the reference site, how to extract it, what makes it checkable, and where it lands in the brief you hand the builder. Existing token content tends to cover taxonomy, extraction tooling, or the WCAG maths separately — the point of running them as one checklist is that every row ends in something you can check against the output.

Each builder exposes a different amount of structure for design-system input, and it’s worth knowing the surfaces as the vendors document them rather than as folklore. v0 supports Tailwind config files and globals.css directly — custom utility classes and CSS variables that its generations respect — and its team-scale mechanism is a registry, which v0’s own docs describe as “a distribution specification designed to pass context from your design system to AI Models.” Teams start from a shadcn/ui-based starter template, define components in registry.json, put color tokens in tokens.css and fonts in CSS variables, then deploy the registry to a public URL that v0 pulls from.

Lovable runs two surfaces. Its Enterprise-tier Design Systems feature stores styling rules, a component library, and setup instructions in a project-level .lovable/ folder that propagates to every connected project. The more broadly available Themes feature is a visual panel over CSS custom properties — colors, typography, spacing, border radius — defined in globals.css. Per Lovable’s docs, project knowledge is ingested by default, with scoping handled by a .dsignore file using gitignore syntax.

Bolt added design-system support that lets teams apply an organization’s brand guidelines inside the builder — with a paid Team plan required to add and reuse a custom design system across projects. Outside that feature, Bolt’s theming is driven by natural-language iteration in chat, a materially looser mechanism than v0’s registry or Lovable’s folder. Replit Agent rounds out the usual shortlist, but we could not find a comparably documented structured theme-file mechanism for it — so rather than speculate, see how v0, Lovable, Bolt and Replit actually compare for the general four-way picture.

Here’s the synthesis the vendor docs don’t state, and the reason this method is worth the hour it takes: all three builders ultimately resolve theme customization down to the same primitive — CSS custom properties in a globals.css or tokens.css file. The differences are how much structure sits around that file: v0’s registry spec, Lovable’s folder plus visual panel, Bolt’s chat with a Team-plan layer. Which means one extracted token set — written once as a THEME.md or a DTCG-format JSON — translates to all three with light reformatting. That’s also why the extraction pairs naturally with Tailwind v4’s token-driven theming, where the theme is likewise CSS variables all the way down. And if the destination is production rather than a prototype, the same brief survives the handoff — see our walkthrough of shipping a Lovable prototype to production.

The boundary we stated in the introduction — extract rigour, not identity — isn’t just etiquette; it tracks how courts have actually treated interface look-and-feel for decades. Copyright protects a site’s specific code and original graphic elements, but not the overall “look and feel” as a gestalt — the combination of layout, palette, and general style — a gap analyzed at length in the NYU Journal of Intellectual Property & Entertainment Law. Trade dress is the doctrine that comes closest to protecting a whole look, but it only covers elements that are non-functional and have acquired secondary meaning — consumers associating that specific look with one source — a bar most site designs don’t clear, as practitioner commentary notes. Functionality is the hard stop: visual choices inextricably linked to their function can’t get trade dress protection at all.

The precedents run one direction. In BlueNile v. Ice.com, courts held that the look and feel of a website as a whole cannot be copyrighted, and later cases have found website styling merely functional and so ineligible for trade dress either — the plaintiff losing on both theories, as summarized in legal-academic commentary. Apple’s 1988–1994 look-and-feel suit against Microsoft over the Windows GUI ultimately failed, with the court distinguishing protectable individual expressive elements from an unprotectable overall look. And Lotus v. Borland — a trial win in 1992, reversed on appeal in 1995, with the Supreme Court declining to reinstate the win in 1996 — established that a menu command hierarchy is a functional “method of operation” and not copyrightable, even though its specific expression might be.

Apply that functional/expressive divide to token extraction and the line draws itself. A spacing base, a numeric type ratio, a neutral-ramp step count, a contrast target — these are functional, systemic choices, the Lotus side of the line, and not realistically protectable. A wordmark, a distinctive illustration style, proprietary iconography — expressive, source-identifying, and squarely on the protected side. This is our reasoned synthesis of the cited case law applied to a new workflow, not a holding from any single case.

The deliverable is a single theme document — we write it as a THEME.md, though a DTCG-format JSON works equally well — with four parts. First, the primitive tables: the color ramp with hex values, the spacing steps with the base unit named, the radius set, the shadow scale with its dark-mode tonal rule. Second, the semantic mappings: which primitive backs which role, with the computed contrast ratio stated next to every text/surface pair. Third, the type system as a base size plus a named ratio and per-tier line-heights. Fourth, a short prose preamble stating what was measured, what was inferred, and — explicitly — that the brief describes structural rigour extracted from a reference, not that reference’s brand identity.

Then the drop-in is mechanical: paste the tokens into v0’s tokens.css or a registry, into Lovable’s Themes variables or a .lovable/ folder, or into Bolt as the opening design-system instruction. The closing move is the one that separates this method from prompt folklore: re-measure the output. Run the same DevTools reads and the same contrast formula against what the builder generated. Because the brief was made of numbers, the review is too — every deviation is a specific, nameable correction rather than another round of “more premium, please.”

Tokens are necessary, not sufficient. They fix theming — color, type, spacing, elevation, motion timing — but they can’t express layout composition, imagery direction, or the choreography of an interaction beyond its durations. For those, the companion method is visual: screenshot-driven UI development with vision models picks up exactly where the token brief stops. And if you’d rather hand the whole extraction-to-production loop to a team that does it weekly, our web development services build on precisely this workflow — measured brief in, verified build out.