Web Design · Systems & implementation
The Best Prompt for a Design System
The best prompt for a design system asks for decisions in layers: raw values first, then semantic tokens that give those values a job, then components built only from those tokens. This prompt takes your existing brand values and a component list and returns token tables, a token file in your chosen format, and a specification for each component covering anatomy, variants, states and accessibility. Contrast figures are flagged for you to verify.
Design System Prompt
Drafts design-system foundations: tiered design tokens, type and spacing scales, and component specs with variants, states and accessibility notes.
- Works with
- ChatGPT, Claude, Gemini
- Difficulty
- Advanced
- Complexity
- Multi-part reply
- Variables
- 6
- Version
- 1.0
Customize this prompt
Fill in what you know. Anything left blank stays as a [bracketed placeholder]. Nothing you type leaves your browser.
6 variables · fields marked * matter most
# Role You are a design systems lead. You favor a small system that is used consistently over a large one that is not. # Context Product: [Product] Existing brand values to keep exactly as given: [Existing brand values to keep] Technology and token format: [Technology and token format] Color modes: [Color modes] Components needed in the first release: [Components for the first release] Principles or constraints: [Principles or constraints] # Part 1 — Foundations Define tokens in two tiers. Primitive tokens (raw values, no meaning): - Color: a neutral scale and one scale per brand hue, with enough steps to cover backgrounds, borders and text. - Typography: font families with fallbacks, a type scale of no more than eight sizes with line heights, and font weights. - Spacing: one scale built on a single base unit. - Radius, border width, elevation, and motion (durations and easing). Semantic tokens (a role, pointing at a primitive): - Surface, text, border, action, focus, and feedback (success, warning, danger, info) roles. - If more than one color mode is requested, give each semantic token a value per mode. Components must never reference primitives directly. State the naming convention in one line and follow it everywhere. # Part 2 — Components For each component in the list, and no others, specify: - Anatomy: its named parts. - Variants and sizes, limited to those with a clear use. - States: default, hover, focus-visible, active, disabled, plus loading, error or selected where they apply. - Tokens used for each part and state. - Accessibility: semantic element or ARIA role, keyboard behavior, and the accessible name source. - One "use when" and one "do not use when" line. # Part 3 — Checks - List every text-on-surface and control-on-surface pairing the system relies on. For each, give your estimated contrast ratio and whether it should meet WCAG 2.2 AA (4.5:1 for body text, 3:1 for large text and for interface components). Mark every ratio [VERIFY]; you cannot measure it reliably. - List decisions you deferred and what information would settle them. # Constraints - Keep supplied brand values unchanged. If one cannot meet contrast in a needed role, say so and propose an adjacent step instead of silently altering it. - No token without a consumer: every semantic token must be used by at least one listed component or a foundation style. - Do not copy the naming or values of a published design system. # Output format Tables for the token tiers and the contrast pairings. One code block containing the full token set in the format named under Technology. A subsection per component.
Use it when you are
- Starting a token set and core components for a new product
- Putting names and structure on an interface that grew without a system
- Adding a dark mode by introducing a semantic token layer
- Drafting component specifications for designers and developers to review together
Why this prompt works
Two token tiers keep meaning separate from value
When a component points straight at a hex code, changing a brand color or adding a dark mode means editing every component. Requiring primitives and semantic roles, and forbidding components from skipping the semantic layer, produces a structure in which a mode is a second set of values for the same names.
The component list is closed
An open request for a design system returns thirty shallow components. Restricting the model to the components you named, and to variants with a stated use, trades breadth for the depth that makes a spec buildable: parts, states, tokens and keyboard behavior for each.
No token without a consumer
Token sets tend to grow speculative entries that nobody uses and everybody must maintain. The rule that each semantic token must be referenced somewhere gives the model a test for inclusion and gives you a quick way to audit the result.
Contrast is estimated, then flagged
Language models are unreliable at calculating contrast ratios. The prompt still asks for the pairings, because knowing which combinations the system depends on is the useful part, and attaches a [VERIFY] marker so no figure is mistaken for a measurement.
How to use it
- Collect the brand values that are truly fixed and paste them exactly. Leave out anything you are willing to change.
- Name the token format your codebase consumes so the code block can be dropped in with little editing.
- List only the components your next release needs. You can run Part 2 again later for more.
- Check the naming convention line first. If it clashes with your codebase, correct it and regenerate before reading further.
- Run every pairing in the Part 3 table through a contrast checker and adjust the semantic tokens that fail.
- Review the component specs with a developer and a designer together, and record changes in the token file, not in individual components.
AI model compatibility
| Model | Status | Notes |
|---|---|---|
| ChatGPT | Expected to work | For more than about six components the reply can run long. Ask for Part 1 first, confirm the tokens, then request Part 2 in a second message with the token names pasted back. |
| Claude | Expected to work | If you paste an existing stylesheet or theme file as brand input, wrap it in <existing_styles> tags as Anthropic's guidance suggests for supplied material. |
| Gemini | Expected to work | Name the token format precisely, for example CSS custom properties or a Tailwind theme object, so the code block matches what your project consumes. |
“Expected to work” means the prompt uses plain, model-independent structure and has been reviewed for that — not that it has been run on that model. A model is marked Tested only when a test record is published below.
Worked example
Scenario: A bookkeeping web app formalizing its interface before adding a dark mode.
# Role You are a design systems lead. You favor a small system that is used consistently over a large one that is not. # Context Product: Ledgerly, a bookkeeping web app for small accounting firms Existing brand values to keep exactly as given: Primary #1F5EFF, ink #101828, typeface Inter, 8px corner radius on buttons Technology and token format: React with Tailwind CSS; output tokens as CSS custom properties Color modes: Light and dark Components needed in the first release: Button Text input Select Checkbox Modal Toast Data table Principles or constraints: Dense, data-heavy screens used all day; keyboard-first users # Part 1 — Foundations Define tokens in two tiers. Primitive tokens (raw values, no meaning): - Color: a neutral scale and one scale per brand hue, with enough steps to cover backgrounds, borders and text. - Typography: font families with fallbacks, a type scale of no more than eight sizes with line heights, and font weights. - Spacing: one scale built on a single base unit. - Radius, border width, elevation, and motion (durations and easing). Semantic tokens (a role, pointing at a primitive): - Surface, text, border, action, focus, and feedback (success, warning, danger, info) roles. - If more than one color mode is requested, give each semantic token a value per mode. Components must never reference primitives directly. State the naming convention in one line and follow it everywhere. # Part 2 — Components For each component in the list, and no others, specify: - Anatomy: its named parts. - Variants and sizes, limited to those with a clear use. - States: default, hover, focus-visible, active, disabled, plus loading, error or selected where they apply. - Tokens used for each part and state. - Accessibility: semantic element or ARIA role, keyboard behavior, and the accessible name source. - One "use when" and one "do not use when" line. # Part 3 — Checks - List every text-on-surface and control-on-surface pairing the system relies on. For each, give your estimated contrast ratio and whether it should meet WCAG 2.2 AA (4.5:1 for body text, 3:1 for large text and for interface components). Mark every ratio [VERIFY]; you cannot measure it reliably. - List decisions you deferred and what information would settle them. # Constraints - Keep supplied brand values unchanged. If one cannot meet contrast in a needed role, say so and propose an adjacent step instead of silently altering it. - No token without a consumer: every semantic token must be used by at least one listed component or a foundation style. - Do not copy the naming or values of a published design system. # Output format Tables for the token tiers and the contrast pairings. One code block containing the full token set in the format named under Technology. A subsection per component.
What a good response should contain
- A primitive color table with a neutral scale and a blue scale that contains #1F5EFF unchanged
- Semantic tokens such as surface, text, border, action and focus roles, each with a light and a dark value
- A single code block of CSS custom properties following one stated naming convention
- Seven component subsections, each listing parts, variants, states including focus-visible, tokens used and keyboard behavior
- A contrast pairing table with every ratio marked [VERIFY], and a deferred-decisions list covering items such as data table density
This is an illustrative scenario showing how to fill in the prompt and what to look for. It is not a recorded model output. Recorded outputs will be published here once this prompt has a test record.
Testing and editorial review
Status: Untested. Reviewed for structure and clarity by the editorial team. No recorded model test yet.
No test record has been published for this prompt yet. When it is tested, this section will show the model and version, the date, the inputs, the actual output and notes against our seven-point rubric. We do not publish numerical scores.
| Author | TheBestPromptFor Editorial Team — The editorial team writes, reviews and maintains the prompts and guides on TheBestPromptFor. Prompts are drafted with AI assistance and reviewed against published editorial standards. |
|---|---|
| Published | November 15, 2026 |
| Last reviewed | November 15, 2026 |
| Last tested | Not yet tested |
| Version history |
|
Limitations and things to check
- Contrast ratios in the output are estimates. Measure every pairing with a proper tool before adoption.
- The model does not know your codebase. Token names and formats may need adapting to existing conventions.
- A design system is also governance, contribution rules and documentation; this prompt covers the foundations and component specs only.
- Typeface suggestions do not account for licensing. Confirm you have rights to any font it proposes.
Alternative prompts
Web Design
Complete Website Design Prompt
A structured brief that walks an AI model from business goals to sitemap, page layouts, visual direction and responsive rules.
- ChatGPT
- Claude
- Gemini
Web Design
Accessibility Audit Prompt
Reviews page markup against WCAG 2.2, separating issues confirmed in the code from those needing manual testing, with fixes and a test script.
- ChatGPT
- Claude
- Gemini
Graphic Design
Brand Identity System Prompt
Drafts a written identity system: color roles with contrast pairings, a type hierarchy, logo usage rules and imagery direction, tied to your positioning.
- ChatGPT
- Claude
- Gemini
Web Development
Responsive CSS Layout Prompt
Builds a layout with Grid, Flexbox and container queries that adapts to its content, with the reasoning and the edge cases to test.
- ChatGPT
- Claude
- Gemini
- Cursor
Related resources
Technical guide
Prompt Chaining: Breaking a Task Into Linked Prompts
How to split a large task into a sequence of focused prompts, design the handoffs between them, and debug the chain when a step goes wrong.
Guide
How to Improve AI Responses
A diagnostic approach to weak AI answers: name the fault, trace it to the gap in your prompt, then follow up precisely or rewrite and start again.
Frequently asked questions
What is the difference between primitive and semantic tokens?
A primitive token names a raw value, such as a specific blue. A semantic token names a job, such as the background of a primary action, and points to a primitive. Components use semantic tokens, so you can change what a role looks like without touching the components.
Should I generate the whole system in one go?
For a handful of components, one pass is fine. For larger lists, generate the foundations first, review and correct them, then ask for components in batches while pasting the agreed token names back in. This keeps later components consistent with decisions you have actually approved.
Can I use this to document a system that already exists?
Partly. Paste your current values and component names as the brand input and component list, and the model will organize them into tiers and specs. It will not know behaviors you have not described, so expect to correct the state and accessibility notes against the real components.
Sources and references
Was this prompt useful?
No account needed. Do not include personal information.