Skip to content

User-first, contract-first

The interface is an agreement, not a handover.

User interfaces go wrong in the gaps: between the research and the story, between the mockup and the component, between what was agreed and what shipped. Closing them takes two moves. Establish two contracts — the design system, which is visual, and the core component library, which is technical and drives the code — and then bring them, already settled, into the sessions where the team decides what to build. They are inputs to story mapping and example mapping, not outputs of them. Once both hold, the pixels are largely settled, and what is left worth checking is whether a real person can get through.

Read the documentationSee the two contracts

One interface, seven people on the hook for it

UI and UX are not a phase that happens before development and a review that happens after it. They are what everyone in this list is holding a piece of — which only works if the pieces are written down as contracts rather than as opinions.

  • “I was in the room where they cut the work up, not in a review afterwards. When I said the confirmation step was the part that frightens me, it became a card on the wall instead of a comment on a screenshot.”

    End user

  • “I stopped delivering screens and started delivering the contract behind them. The tokens and the component states are the handover now — the screens are just the argument for why they look like that.”

    UX designer

  • “The library tells me what a button is. That removed the entire class of question I used to spend a day a week on, and it means a design change reaches every screen at once instead of screen by screen.”

    Front-end developer

  • “The day the tokens stopped being copied by hand was the day the design system became real. Before that it was a document two teams politely disagreed with.”

    Design system maintainer

  • “We used to argue about whether a shade of grey was right. Now that is settled in one place, and the standups are about whether the journey works — which is the only thing I can actually defend to a stakeholder.”

    Product owner

  • “I test the journeys and let the snapshots watch the pixels. Once the components are under contract, a screenshot diff mostly tells me a component changed on purpose; a broken journey tells me a user is stuck.”

    Quality engineer

  • “Accessibility used to arrive as an audit six weeks before release, when the only affordable fixes were cosmetic. Put it in the component contract and it ships by default — I get to work on the hard cases instead.”

    Accessibility specialist

Areas