Design systems / Practical guide

# Design tokens for AI prototypes: start with one screen

A small token file and a prompt your builder can reuse.

[By CRRT](/)·November 2, 2026·3 min read

[← All resources](/resources)

## The short answer

Design tokens are named values for recurring design decisions, such as text color, spacing, and corner radius. For an AI prototype, start with the values used on one approved screen, name them by purpose, and ask your builder to reuse them before adding new styles.

## 1\. Choose a screen worth repeating

Use a screen that already feels like your product. A settings page with fields, buttons, headings, and a panel is a better starting point than a decorative landing-page hero. If the product is new, approve one representative screen before generating several more.

List the decisions that repeat: page and panel backgrounds, primary and muted text, action and border colors, spacing, type sizes, and corner radii. Keep this first inventory small enough to review in one sitting. Record what is actually used rather than inventing a complete scale for hypothetical screens.

## 2\. Name values by their job

A name such as color-text-muted explains where a value belongs. A name such as gray-400 describes its appearance. Both can exist in a larger system, but a small prototype benefits from clear purpose-based names at the point of use.

The following values are an illustrative starting point, not CRRT’s brand tokens. Replace them with your approved screen’s values. Keep the file in the repository so both people and coding agents can find it.

Copy & adapt

```
:root {
  --color-surface: #ffffff;
  --color-text: #202329;
  --color-text-muted: #646b75;
  --color-action: #2256b8;
  --color-border: #d9dce1;
  --space-control: 12px;
  --space-section: 24px;
  --radius-control: 8px;
}

.form-panel {
  background: var(--color-surface);
  color: var(--color-text);
  padding: var(--space-section);
}
```

## 3\. Give the builder a bounded instruction

Provide the file path, an approved reference, and the screen to update. Ask the builder to report missing tokens before creating them. This gives you a chance to distinguish a genuine new need from a variation the existing system already covers.

Copy & adapt

```
Update the account settings screen using styles/tokens.css.
Use the billing screen as the visual reference.
Reuse existing form and button components.
Replace repeated raw values with the matching semantic tokens.
Preserve the current copy, field behavior, and layout.
List any missing token roles before adding them.
Show the changed screen at narrow and wide widths.
```

## 4\. Review the screen and the change

Check the running page next to your reference. A token file can be correct while a component still overrides it locally. Inspect the implementation for repeated raw values and verify that focus, hover, disabled, and error states remain clear.

When you find drift, point to one affected element and describe the rule it should follow. For example: “The secondary action uses a different radius from the other form controls. Reuse the control radius token.” CRRT can preserve the selected element and visual feedback when you hand an accepted correction to a coding agent.

*   Compare text and background pairs for readable contrast.
*   Test narrow layouts with long field labels and realistic content.
*   Check one second screen to confirm the tokens actually transfer.
*   Review new token additions and remove duplicate roles before merging.

## Common questions

### Do I need a complete design system before prototyping?

No. Start with one approved screen, shared values, and a few reusable components. Expand the system when a real screen requires a new decision.

### Can design tokens stop every visual inconsistency?

No. Tokens standardize values. Layout, component behavior, content, and responsive decisions still need explicit instructions and review.

## Sources & further reading

*   [Design Tokens Community Group: specification and terminology](https://www.designtokens.org/)
*   [v0: using your own design system](https://v0.app/docs/design-systems-2)

Written with AI assistance. Tool references checked against the linked documentation on November 2, 2026. Examples are starter templates to adapt and review in your own project.

Keep going

## Put the next piece in place.

[

Practical guide · 3 min read

### How to document components for coding agents

A reusable component brief for your existing library.



](/resources/document-components-for-coding-agents)[

Practical guide · 4 min read

### A UI review checklist for AI-generated apps

A practical review checklist for your next release.



](/resources/ui-review-checklist-ai-generated-apps)

## See something off? Ship the fix.

Pin the feedback. Give your coding agent the context. Review what comes back.

[Try CRRT](/docs/install)