User interfaces: Clarity in every click.

UI design built on states, not just screens

What we design

Our UI design work covers every state a control can be in, from resting to broken: default, hover, focus, active, disabled, loading, error and empty. A button mock-up that only shows the happy path isn't a finished design — it's a third of one. We design and build these states together, because a state that only exists in Figma and never reaches the browser is a state nobody will ever see.

Patterns people already know

We follow the interaction patterns documented in the WAI-ARIA Authoring Practices Guide for anything beyond a plain link or button — menus, tabs, dialogs and disclosure widgets each have an expected set of keys and roles, and departing from them without reason breaks assistive technology and muscle memory alike. Every interactive target is sized and spaced to the W3C's 24×24 CSS pixel minimum, with touch interfaces held to a more generous standard again, because a control that's technically clickable but hard to hit is a design that hasn't finished its job.

What we refuse to cut

Focus indicators stay visible — we never ship outline: none without a replacement that's at least as visible, because removing it silently locks out keyboard and switch-device users. Forms validate on submission with errors written as instructions rather than blame, following the pattern set out in MDN's forms guidance. And usability isn't guessed at: we test flows against established heuristics such as Nielsen Norman Group's ten usability heuristics before calling a screen finished.

What this depends on

Interfaces that behave well for everyone come from designing states and keyboard behaviour from the first sketch, rather than patching them in afterwards. Interfaces don't stand alone — they rest on the structure covered under accessibility, and a screen that looks right but ignores either will eventually fail someone. Every state we design is built the same way in code, as part of our custom website development work.