Overview
Most design problems are not visual. A screen feels confusing because the underlying model is confusing, or because it was designed for the person who commissioned it rather than the person who uses it forty times a day. Making that screen prettier does not fix it.
How we work
- Research. Talking to real users and watching them work. Twenty minutes of observation routinely overturns an assumption everyone was confident about.
- Information architecture. What the system contains, how it is grouped and what people are trying to accomplish — settled before any screen is drawn.
- Wireframes. Structure and flow resolved in low fidelity, where changes are cheap and nobody argues about colour.
- Prototypes. Clickable, and put in front of users. It is far cheaper to find a problem here than after it is built.
- Visual design. Applied to a structure that already works, on a token system rather than as one-off screens.
- Handover. A documented system with components, states, spacing and behaviour — not a flat file and good luck.
Designing every state
The demo screen is the easy one. We design the empty state, the loading state, the error state, the one-item and the ten-thousand-item state, the long-name state and the permission-denied state. These are most of the real experience and they are where handovers usually fall apart.
Accessibility
Built to WCAG 2.2 AA from the start, not audited at the end. Colour contrast checked at design time, focus states designed rather than deleted, touch targets sized for fingers, and no meaning carried by colour alone. Accessible design is clearer design for everybody.
Design systems
For products that will keep growing, the deliverable is a system: tokens for colour, type, spacing and elevation; components with every state defined; usage rules; and documentation developers can build from directly. It is what stops the fourth developer inventing a fifth button style.
What you get
- Research findings, written down, including the things that contradicted the brief.
- Wireframes and a clickable prototype tested with real users.
- Visual design on a documented token system.
- Every state designed, not just the happy path.
- A developer-ready handover with components and behaviour specified.
If users need training to complete a core task, that is a design defect, not a training gap.