Design every consequential state

01 / Learn

The idea

An interaction contract names the states a workflow can enter, the events that move it, and who is permitted to act. A purchase request may be draft, submitted, under review, returned for edits, waiting for a second approver, approved, rejected, or stale because the requester changed it. Designing only the default review screen leaves important decisions undefined.

For each state, ask what the actor must know, what actions are allowed, what happens next, and how an error is recovered. The information shown at approval should include decision-critical context and a clear consequence. A generic confirmation after a click cannot compensate for an outdated request or an unauthorized approver. Test how people understand status after their part is complete.

02 / See the reasoning

Worked example

Fictional scenario

A manager receives a purchase approval request with a title and an Approve button.

An approver opens an old notification after the amount changed. An expert prevents approval of that old version and shows the changed fields before another decision. The request may then continue to a second approver, so the first approver sees 'Your review is complete; final approval pending' rather than 'Approved.' The labels match the workflow state.

03 / Decide

Guided decision

The team can add one review step. Which approach would you prototype, and what assumption must be checked?

04 / Apply elsewhere

Independent application

Fictional scenario

An administrator publishes a revised public policy; some comments remain unresolved and legal review may be pending.

Create a state model from draft to published or returned for edits. Include roles, changed versions, customer notification, and recovery after a mistaken publication.

Make: An annotated state model and short rationale for the review step.

05 / Keep working

Sources and related patterns

• U.S. Web Design System: Establish Trust ↗

Apply this skill: Design decision memo and state model →