Verified against ChatGPT · 2026-08-08
Turn a pile of inconsistent screens into a design system starter kit with a token audit and a component priority list
Feeds ChatGPT a description of your current, inconsistent UI and gets back a proposed token structure (color, spacing, type, radius), a prioritized list of which components to systematize first, and the specific inconsistencies to kill before anyone touches Figma.
The prompt
Ready to copy — highlighted parts are example details you can swap.
You are acting as a design systems lead brought in to propose the starting structure for a design system for a product that currently has none — just screens built ad hoc by different people over time. PRODUCT AND CURRENT STATE A B2B scheduling SaaS with about 40 screens, built by three different contract designers over 18 months with no shared file or style guide. KNOWN INCONSISTENCIES Primary buttons appear in four different blues across the app; card corner radius is 4px in some flows and 12px in others; there are at least three different type scales in use for body text. TEAM SIZE AND TOOLING Two product designers, four frontend engineers, everyone on Figma but no shared component library yet, frontend uses a homegrown React component set with no token file. WHAT MUST SHIP FIRST A redesigned onboarding flow (5 screens) needs to ship in 3 weeks and should be the first thing built with the new system. Do not propose a full token taxonomy lifted from a well-known public design system (Material, Carbon, Polaris) and relabeled — propose a token structure sized to the inconsistencies actually described above, and say explicitly which layers (primitive tokens, semantic tokens, component tokens) this team genuinely needs versus which would be premature abstraction for a team this size. For each known inconsistency listed, name the specific token or rule that would have prevented it, not a generic "establish a color palette" recommendation — trace the fix back to the actual symptom. Propose a component inventory ordered by a stated prioritization logic (frequency of reuse across the product, visual inconsistency severity, or blocking status on the first deliverable) and say which logic you used and why, since these three orderings can produce different lists and a silent choice between them hides a real trade-off. Flag anywhere the described tooling (or its absence) would make a proposed structure unworkable in practice — for example, recommending component-level tokens when the team has no shared component library yet to attach them to. OUTPUT FORMAT 1. Token structure: which layers to build now, which to defer, with 2-3 example tokens per layer named specifically enough to paste into a tokens file. 2. A table of the top 6-10 components to systematize first, each with the inconsistency it currently has and the prioritization logic used to rank it. 3. A short list of naming convention rules for the tokens (e.g. how color-role tokens should be named) so two different people building screens converge instead of diverging further. 4. One paragraph on what to explicitly defer past the first deliverable, and why deferring it now is safer than building it early.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
The instruction to name which token layer (primitive, semantic, component) is actually needed rather than defaulting to the full three-tier structure directly counters GPT-5.1's tendency to reach for the most complete, textbook-looking answer regardless of team size — a two-designer team with no component library yet gains nothing from component-level tokens and actually loses time maintaining a layer with no consumer, but a model asked generically to "propose a token structure" will reliably produce the full stack because that's the modal pattern in its training data on design systems content, most of which comes from large companies like Google or IBM writing about systems built for hundreds of contributors. Requiring each recommendation to trace back to a specific listed inconsistency forces the token proposal to stay diagnostic rather than aspirational — it's a structural check against the common failure mode where a systems proposal reads as generically correct but doesn't actually address the specific mess described, because nothing in the prompt held the model accountable to using the input data rather than pattern-matching to "what design systems usually contain." Naming the prioritization logic explicitly (reuse frequency vs. inconsistency severity vs. deadline-blocking) surfaces a real trade-off that's usually made silently and inconsistently by whoever's writing the plan; making the model commit to and state one logic means a reviewer can actually disagree with the ordering on its stated merits rather than accept an unexplained list. The tooling-gap flag matters because a proposal that's internally coherent as design theory can still be operationally impossible — recommending component tokens with no shared component library to attach them to is the kind of gap a model won't self-catch unless explicitly told to check for it, since nothing about the recommendation looks wrong in isolation.
What you get back
Token structure: build primitive + semantic layers now (color-primitive-blue-500, color-role-action-primary); defer component-level tokens until a shared React component library exists. Top components to fix first (ranked by inconsistency severity, since three colliding blues is actively confusing users): 1. Primary button, 2. Card container, 3. Body text scale... Naming convention: role-based, not value-based (color-role-action-primary, not color-blue-1). Defer: full component token layer — building it now with no shared component library means maintaining tokens nothing consumes yet.
Verified against
ChatGPT GPT-5.1 · 2026-08-08
Changelog
- 2026-08-08 — Initial publish, verified against ChatGPT GPT-5.1.
Need this built into your business?
If a prompt isn't enough — branding & design, built and maintained for you — that's Scult's day job.
EXPLORE BRANDING & DESIGN
