Interface contract

The UX team and the dev team are peers. They run at the same time. Dev does not wait for finished designs — so if UX's first output is polish, dev either idles or invents its own contract, and the two diverge.

The fix is to ship the contract before the visuals. It is deliberately ugly and deliberately early.

What it contains

Screen inventory — every screen or view this feature adds or changes, named.

Component list — the components each screen needs, distinguishing new ones from reuses of existing ones. A new component is a cost; say so.

Every state, per screen. This is the part that gets skipped and the part dev actually needs:

• empty (no data yet)
• loading
• partial (some data, some pending)
• error, per distinguishable error the backend can return
• over-limit / truncated (more data than the design assumed)
• permission-denied, if the feature has any access control

A design with only the happy state is not a contract — it is a mood board, and dev will invent the other six states itself.

Data per screen — what each screen needs from the backend: fields, types, cardinality, and which are optional. This is what dev builds against. Name the shape even if it is provisional; a provisional shape you can build against beats a perfect shape that arrives late.

Interaction contracts — what each control does, what it optimistically updates, what requires confirmation, and what is irreversible.

Freezing and changing

Once the contract is agreed at G2, changing it crosses a team interface and therefore flags (see flag-check). That is intentional: a silently changed contract is how a UX team and a dev team ship two different features.

Then refine

With the contract shipped, the UX team returns to visual design — hierarchy, typography, color, motion — using frontend-design, ui-ux-pro-max, and web-design-guidelines. Accessibility findings are defects, not suggestions.

Deliver visuals as rendered screenshots, never as descriptions of a design. See delivery.