Design & UX · master area
Interaction Design
What happens between states. Transitions, hover, focus, loading, optimistic UI, undo. The behaviour code will need to support — designed before code begins.
Owners: Designer Phase it lives in: What We Build → How We Build (Volumes III and IV) The corpus principle this enacts: Name every state the person can be in — including the moments between states.
Where it lives in the chain
- What We Build · Design Shaping — where states are first named
- How We Build · Design Execution · handoff — where interaction behaviour becomes annotation
How to do this
- Practice — Holding amigos — interaction states feed scenarios
- Principle — Chain-level thinking
- Clinic — A story without a state — the absence this craft fills
What good output looks like
For every state on the flow, the designer names: what the person sees in the transition (skeleton, spinner, optimistic), what they can do during it (cancel, retry, nothing), how it ends (success snap, error message, timeout). Focus and hover are part of the spec, not decoration. Long actions get a name (saving…, reconciling…) so the support ticket doesn't say "it froze" — it says "it stayed in reconciling… for 40 seconds." Interaction design that stops at "the button is blue" is interaction design that produces bug reports the team can't reproduce.
Related crafts
- Design System — where the patterns live
- User Flow Design — the nodes these interactions move between
- Component Development — where the interaction becomes code