References in a Design System

A design system records accepted rules. A reference library records the visual evidence, alternatives, and project context that helped the team accept them. Keeping the two connected makes the system easier to explain and evolve without treating screenshots as specifications.

References come before rules

During exploration, references help the team compare possible structures, interaction patterns, type hierarchies, and visual treatments. Most examples will not become system guidance. The useful ones reveal a recurring problem, a credible approach, or an edge case the current system does not cover.

Once the decision is made, translate it into the appropriate system layer: a semantic token, component behavior, page pattern, content rule, accessibility requirement, or documented exception. Figma’s variables guide explains the mechanism for reusable values; the design team still has to define their meaning.

Link evidence to the decision

For an important component or pattern, preserve a compact decision record:

• the problem and constraints;
• two or three references that informed the discussion;
• the chosen rule and rejected alternatives;
• known limits and responsive states;
• the Figma component and production implementation;
• the owner and review date.

The reference board does not replace component documentation. It explains where the rule came from and what evidence should be reconsidered when requirements change.

Map observations to system layers

A reference may suggest that muted text still needs reliable contrast, but the reusable result is a semantic color role. It may show a balanced card rhythm, but the system needs spacing tokens, content limits, and responsive behavior. It may reveal a useful pricing comparison, but implementation requires a pattern with states and accessibility expectations.

The U.S. Web Design System describes design tokens as a limited set of named design decisions. References are valuable because they show those decisions working together in context; tokens make the accepted parts consistent.

Separate exploration from current guidance

Use distinct boards or statuses for raw research, shortlisted evidence, approved precedent, and retired guidance. A reference that inspired an earlier version may remain historically useful without representing the current system.

When a rule changes, update the design-system documentation first, then revise the linked evidence and decision note. Do not let an old screenshot silently overrule the maintained component.

Review references with the system

Include linked evidence in component and pattern reviews. Ask whether the original problem still exists, whether the examples still represent the intended behavior, and whether new products, languages, content lengths, or accessibility needs expose a missing case.

Start with the broader guide to what a design system gives a web designer, then connect one frequently used component to a small Refframe board. If the next contributor can understand both the rule and its rationale, the connection is doing useful work.