01
User interviews
One-to-one conversations with the people doing the work, in their environment where possible. We ask about last week, not about hypotheticals — memory of a real task beats speculation every time.
Design
Stop guessing what your users need.
Most software gets built on an assumption nobody checked. UX research replaces that assumption with evidence — gathered from the people who will actually use the thing, doing the job they actually do.
Why it matters
The short version.
There is a specific kind of expensive failure that only shows up after launch: the software works exactly as specified, and nobody uses it. The specification was the problem. It captured what somebody believed the job looked like, and the belief was slightly wrong in a way that only becomes obvious when a real person sits in front of the screen at 7am with a phone ringing.
Research is the cheapest insurance against that. Two weeks of interviews and testing costs a fraction of a build, and it either confirms your plan — which is genuinely valuable, because you proceed with confidence instead of hope — or it redirects you before the money is committed.
The uncomfortable part is that research frequently contradicts the person who commissioned it. We would rather deliver that early and awkwardly than let you discover it eighteen months later in your churn numbers.
Research either confirms your plan or redirects it. Both outcomes are worth more than the cost.
Is this you?
You probably need this if…
- Your team disagrees about what to build next and nobody can settle it
- Usage numbers are fine but people complain anyway
- Support keeps answering the same "where do I find" question
- You are about to spend real money on a build and want to de-risk it
What's involved
The actual work.
No two engagements are identical, but this is the shape of it.
02
Usability testing
We put something in front of five to eight real users and watch where they stall. Five users reliably surfaces the large majority of serious usability problems, which is why we rarely need more.
03
Journey & workflow mapping
The full path, including the parts that happen on paper, over the phone, or in somebody's head. The gaps between systems are usually where the pain lives.
04
Analytics review
What your existing numbers already say, read honestly — including the drop-offs everyone has learned to stop noticing.
What goes wrong
Mistakes worth
avoiding.
Named plainly, because most of them are easier to avoid than to undo.
-
Asking people what they want
People are poor at predicting their own future behaviour and excellent at describing what they did last Tuesday. We ask about the specific, recent and concrete, not the hypothetical.
-
Only talking to the enthusiasts
The people who volunteer for interviews are rarely representative. The person who quietly stopped using your product has more to tell you than the champion who loves it.
-
Treating research as a phase that ends
The assumption you validated in January can be wrong by September because your market moved. A little research repeatedly beats a lot of it once.
How it runs
Start to finish.
Each phase ends in something you can open, click or read.
-
01
Scope
We agree the questions worth answering. Research with no decision attached is a hobby, not a service.
-
02
Fieldwork
Interviews and sessions, recorded with permission. Usually one to two weeks.
-
03
Synthesis
Patterns across participants, separated from one-off opinions.
-
04
Readout
A working session where we walk your team through it, then hand over the written summary.
Deliverables
What you walk
away with.
Yours to keep, whatever happens next.
Findings written in plain English, not research jargon
A prioritised list of problems, worst first
Clips from the sessions — watching a user struggle ends debates fast
A clear recommendation on what to build, change or drop
Questions
Worth asking.
Anything else — email hello@haddon.software and a human replies the same business day.
Usually five to eight for usability testing. Past that you start hearing the same things again, and the budget is better spent acting on what you found. For broader discovery interviews we typically do eight to twelve across different roles.
Yes, though it changes shape. We would talk to people who have the problem you are solving rather than people using your product, and lean harder on competitive and market analysis. We will be clear about what that can and cannot tell you.
Absolutely, and plenty of clients do. You own the findings and can hand them to any team. We would rather you act on good research elsewhere than sit on nothing.
Yes, and we encourage it — watching a user struggle with something your team built is more persuasive than any report we could write. We keep observers muted and out of the participant's view so it does not change their behaviour.
Then you have learned something valuable for the price of a two-week engagement rather than a full build. We present findings plainly, including the inconvenient ones, and we will show you the evidence rather than asking you to take our word for it.
Related
You might also need…
Want to talk it through?
The first call is free, runs about thirty minutes, and you'll get a straight answer about whether we're the right fit — including when we're not.