We design products by watching people use them. Every engagement opens with five to eight moderated sessions on the current experience or a rough prototype, because an hour of watching someone struggle settles arguments that a month of reviews will not.
Research that fits in a sprint
This is not a six-month ethnography. Five sessions reliably surface about 80% of usability problems, and they can run inside a single week. The output is a ranked list of what is actually costing you conversions — not a deck.
2.1x
Onboarding completion after one round of research on a fintech product
On that project the fix was not visual at all. People abandoned at the address step because it asked for a document they did not have to hand; moving the upload to the end of the flow accounted for most of the improvement.
Every state, not just the happy path
Most design files show the screen with perfect data. Real products spend their time empty, loading, offline, or in error. We design those states too, because otherwise an engineer invents them at 5pm on a Friday.
- Empty, loading, partial, error and success for every meaningful view
- Focus order and keyboard paths defined, not left to the DOM
- Contrast checked as the design is drawn, not audited afterwards
- Motion specified with a reduced-motion alternative
A system, not a stack of screens
The deliverable is tokens, components, states and the rules for combining them, handed over in a form engineers implement without interpretation. We sit in build reviews specifically to catch the gap between what was drawn and what got made.
The best compliment I get is an engineer telling me there was nothing to ask about.