Interaction Contracts

Make the behaviour of a named interaction explicit enough that designers and engineers can build and verify the same experience. A contract describes observable promises; it does not require a state-machine library or a particular architecture.

Find the unresolved promise

Use the existing brief, interface, component API, and implementation to identify the person, task, starting state, and supported inputs. Preserve established behaviour unless the task calls for changing it. Distinguish a requirement from observed behaviour and a proposed change.

Cover the consequential uncertainty, not every possible event. An already specified local edit needs only the affected promise. Ask when a missing product decision would materially change the contract; otherwise state a reasonable assumption and proceed. A request for a specification authorises a specification; implementation requires an implementation request.

Describe the observable contract

Use a compact table, annotated flow, or the team's existing format. Include what matters for the interaction: