The fastest way to waste a research budget is to buy findings. Findings are interesting. Decisions are what you are paying for, and the difference shows in the deliverables.
The four things worth paying for
- A ranked list of the problems worth solving, with the evidence for each and an honest note on how confident we are.
- The two or three decisions the research changed, stated plainly, including the ones that killed an idea the team liked.
- Verbatim evidence: what people actually said and did, kept intact enough that anyone can check our reading of it.
- A design intent: what we now believe the product should do differently, small enough to start on Monday.
If nothing in the research changed a decision, it was journalism, not research.
What to reject
Personas with names, ages and a stock photo, and no behaviour that would change a design decision. Journey maps drawn entirely in a workshop from what the team assumes. Any deck whose conclusions could have been written before the fieldwork, because those are the ones that usually were.
How much is enough
Five well-run sessions per segment will find most of the severe usability problems. Twelve to fifteen interviews will usually saturate the themes for a single service. Beyond that you are buying confidence, not new information, and there are cheaper ways to buy confidence, like shipping something small and watching.
Where it usually goes wrong
Not in the fieldwork. In the handover. Research that lands as a document nobody opens changes nothing; research that lands as a ranked list a product owner can argue with changes everything. Insist on the second, and insist that whoever ran it sits in the room while the design decisions are made.
Common questions
What should a research phase deliver?
Decisions, not documents. The useful outputs are a clear statement of the problem, a prioritised list of what users actually struggle with, the evidence behind each point, and a set of recommendations that change what gets built next. A slide deck summarising interviews is a by-product, not the deliverable.
How long should a discovery or research phase take?
Two to four weeks for most product and website projects. Long enough to speak to real users, review the data and synthesise; short enough that the findings still describe the current situation when design starts.
How do you know research was worth the budget?
Ask what decision changed because of it. If the team would have built the same thing without the research, the phase produced reassurance rather than insight.