Write product states plainly — Design Field Note

01. State is a contract

A label such as submitted or approved creates an expectation. Define the event that earns the label, the owner, and whether it can be reversed.

In practice, document one concrete example and one counterexample. Ask the team to identify the actor, source of truth, time boundary, and recovery path. Then test the wording or pattern with realistic information rather than ideal placeholder content. This reveals ambiguity, overflow, missing states, and operational promises before they become expensive.

A useful review question is: what would a person reasonably believe after seeing this? Compare that belief with what the service can actually deliver. If they differ, change the language, interface, or operation—not merely the presentation. Record the decision so future contributors understand why the pattern exists and which evidence would justify changing it.

02. Lead with meaning

Begin with what the person needs to understand. Internal processing detail belongs later unless it changes the next action.

03. Distinguish waiting from failure

Waiting needs a timeframe or update trigger. Failure needs recovery. A spinner without either transfers operational uncertainty to the user.

04. Write the next action

Use a verb, object, and consequence: upload proof of address to continue review. Avoid vague prompts such as resolve issue.

05. Represent uncertainty honestly

Use ranges and conditions where exact timing is not controlled. Explain what can cause change and where the newest status appears.

06. Design errors as routes

An error message should preserve entered work where safe, identify the affected field or service, and offer a reachable route forward.

07. Plan for translation

Keep sentences direct, avoid embedded clauses, and allow expansion. Test dates, names, addresses, and plural forms with real locale rules.

08. Review with operations

Support and operations teams know recurring misunderstandings. Bring their examples into content review and track whether revised language reduces repeat contact.

Run a review with real material

A pattern is not ready because it works with a short name, a perfect connection, and a cooperative default path. Review it with long organization names, translated strings, missing values, duplicate records, interrupted sessions, stale status, and information that arrives out of order. Include people using a keyboard, zoom, reduced motion, and assistive technology. The point is not to create an exhaustive laboratory; it is to expose assumptions that the polished example concealed.

During review, ask participants to narrate what they believe has happened and what they expect next. Do not correct their interpretation immediately. Their language shows whether hierarchy, state, and instruction are doing the intended work. Note where they seek reassurance, whether they distinguish an estimate from a commitment, and whether the recovery route is visible before frustration becomes abandonment. Pair observations with operational data such as repeat contacts, manual corrections, completion time, and unresolved cases.

Document the decision, not only the artifact

For every consequential pattern, keep a short decision record: problem, evidence, chosen response, alternatives considered, known risks, owner, and date for review. Link the record to the component or content pattern that implements it. This keeps later contributors from removing an important constraint because it looks like an arbitrary visual choice. It also makes disagreement productive: a proposal can challenge the evidence or supply new evidence instead of restarting a discussion about preference.

Documentation should be close enough to production that teams encounter it while working. A small, current record beside a component is more useful than a comprehensive manual nobody opens. Include one correct example, one misuse, content limits, responsive behavior, accessibility notes, analytics or service measures, and the path for requesting an exception. Review the record whenever the underlying service, policy, data source, or technical behavior changes.

Close the loop after release

Set a review date before launch and decide which signals will trigger an earlier review. Useful signals include repeated support questions, abandoned tasks, manual workarounds, accessibility defects, inconsistent new variants, and a changed source of truth. Numbers need context: a reduction in completion time may be positive, or it may mean people are giving up sooner. Pair quantitative measures with examples from real cases and the judgment of operational staff.

Share findings in the same language as the original objective. State what changed, what remains uncertain, and which team owns the next decision. Preserve a small sample of failures as regression scenarios so future releases are tested against what the organization learned. This turns research and quality review into a durable feedback route rather than a one-time approval ceremony.

Working checklist

Before release, name the user objective, consequential decisions, source of truth, non-default states, owner, update trigger, accessibility checks, and recovery route. Review with the people who operate the service and at least several people who do not share the team’s vocabulary. Publish known limitations beside the claim they qualify.

This note offers general design practice, not legal, clinical, engineering, or policy advice. Requirements vary by service, jurisdiction, technology, and risk. Teams remain responsible for specialist review and for testing their own implementation.