Test the state missing from the mockup

Before reusing a pattern, inspect the conditions its default screen hides.

Chris Carter1 min readDesign systems

A candidate pattern is tested against empty, error, and permission states. Shared review then decides whether to keep it local, revise it, or promote it.

A candidate pattern is tested against empty, error, and permission states. Shared review then decides whether to keep it local, revise it, or promote it.

Open diagram at full size

The default screen can make a pattern look ready for reuse. Missing information, long content, restricted access, and recovery often reveal whether its behavior fits the wider product.

Use clearly synthetic scenarios to examine these states without importing private data. The aim is to expose a product decision while the pattern is still easy to change.

Put it to work

  1. Choose one pattern proposed for reuse and name the user problem it serves.
  2. Prepare examples with no data, long content, limited permission, an error, and a recovery action.
  3. Inspect the coded component, tokens, semantics, and keyboard behavior in those states.
  4. Invite a consuming team to review the awkward case and explain what a user would do next.
  5. Decide whether to keep the pattern local, revise it, or promote it. Record its owner and when it should not be used.

Read the full essay

This note is adapted from “A Design System Needs Evidence Before Scale.” The essay develops the argument, includes an interactive framework, and links to further reading.