Design systems / Practical guide

# What belongs in a minimum viable design system?

A small system you can apply and review in a real flow.

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

[← All resources](/resources)

## The short answer

A minimum viable design system contains the shared values and components needed for a real product flow, plus usage rules and a way to maintain them. Start with an approved screen, semantic tokens, frequently used controls, state examples, and an owner for changes.

## 1\. Choose a real flow as the boundary

Select a flow the team is actively building or refining. A project creation flow might need headings, fields, buttons, a dialog, and a notice. It probably does not need every chart, navigation pattern, and commerce component the product could eventually contain.

List the decisions that repeat across that flow. Use the approved implementation and design reference to distinguish a shared decision from a one-off arrangement. The word “minimum” describes a useful boundary; it does not justify leaving behavior or accessibility undefined.

## 2\. Capture values and components together

Name the recurring color, spacing, typography, and radius decisions by purpose where practical. Then connect those tokens to the controls people actually use. A token inventory without consumers does not tell a builder which component belongs on the next screen.

Record the component’s location, supported variants, and an example that works. Explain when to use an alternative, such as a link for navigation instead of an action button. Keep documentation close to the implementation or link it clearly from the project entry point.

Copy & adapt

```
First system release
Reference: one approved product flow and its design frame
Tokens: surfaces, text, actions, borders, spacing, type, radii
Components: the fields, actions, and notices used by that flow
States: default, focus, disabled, loading, error, success
Usage: location, supported variants, example, alternatives
Ownership: who approves changes and resolves exceptions
Verification: one second screen built with the same system
```

## 3\. Document the states that change the task

Build examples with realistic content and failure conditions. A field needs more than its empty default appearance. Show what happens when input is invalid, when a request is pending, and when a label or value is longer than expected.

Use Storybook if it is already part of the project, or another runnable example that reviewers can reach. The goal is a reliable way to inspect the component’s behavior and appearance. Adding a documentation platform is a separate decision from making the first component understandable.

*   Show a keyboard focus state and check the accessible name.
*   Explain whether a pending action can be activated again.
*   Include long content and a narrow layout.
*   Review both themes when the product supports them.

## 4\. Prove reuse and establish ownership

Apply the system to a second screen. Ask a teammate or coding agent to locate the documented components and build a small change with them. Review whether the result uses supported variants and existing tokens instead of creating similar local alternatives.

Assign someone to approve new patterns and retire duplicates. Keep an exception record when a real need is not covered, with a reason and a review point. Repeated visual feedback can reveal where the system needs a better rule; one unusual screen does not automatically require a new global component.

## Common questions

### How many components should the first release contain?

Use the components needed for the selected flow and a meaningful reuse test. A fixed component count would ignore the product and the work the team needs to complete.

### Can a coding agent create the system for me?

An agent can help inventory values, draft examples, and apply approved patterns. A person still needs to resolve design decisions and review the resulting behavior.

## Sources & further reading

*   [Design Tokens Community Group: shared design decisions](https://www.designtokens.org/)
*   [Storybook: documenting components](https://storybook.js.org/docs/writing-docs/index)

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

### Design tokens for AI prototypes: start with one screen

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



](/resources/design-tokens-for-ai-prototypes)[

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)

## See something off? Ship the fix.

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

[Try CRRT](/docs/install)