What belongs in a minimum viable design system?

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.

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