What are the actual deliverables of a UX research phase?

Research findings, journey maps, user stories and prototypes — but the test of each is whether it changed what got built. A journey map that decorates a wall is a cost; one that shows the drop-off nobody had noticed is the cheapest thing in the project. Ask any agency what a deliverable will let you decide, and be wary if the answer is a document count.

How much user research is enough?

Enough to stop being surprised. In practice that is a smaller number of participants than people expect — patterns repeat quickly — and the discipline is knowing when to stop rather than running a fixed quota. Research that keeps producing new surprises has not finished; research producing the same five observations is done.

Is UX research worth it on a small project?

Often yes, at a smaller scale. The value is not the artefact, it is avoiding building something nobody uses, and that risk does not scale down with budget. A week of research on a modest build is usually cheaper than a month rebuilding a feature that missed.

What a UX Research Phase Actually Produces

Research is the easiest phase to cut and the most expensive one to skip. It is also the phase most often sold badly — a fixed number of interviews, a deck at the end, and no clear line between what was learned and what got built.

The useful question is not “how much research” but what does it have to produce for the build to be different because of it?

The short answer

A research phase should end with four things, and each one should change a decision:

Output	The decision it changes
Research findings	Whether the thing being built is the right thing at all
Journey map	Where the product needs to work hardest, and what to cut
User stories	What “done” means, story by story
Prototype	Whether the solution works, before anyone builds it

If a deliverable does not change a decision, it is documentation, not research.

Research findings

The point of interviews and analytics is to find where the current experience actually breaks — not to confirm what the team already suspects.

The most valuable findings are usually the boring ones. People do not abandon a form because it is ugly; they abandon it because it asks for a number they do not have to hand. They do not fail to find a document because search is bad; they fail because the thing is filed under a word nobody outside the organisation uses.

Two things make findings usable rather than interesting:

Frequency and cost together. “Three of eight participants could not complete this” is a finding. “Three of eight could not complete it, and it is the step before payment” is a priority.
Named, not anonymised into mush. “Users want it to be simpler” is unusable. “Members who joined before 2019 have a card number in a different format and the field rejects it” is a ticket.

Journey maps

A journey map earns its place when it shows where the work should go — not when it renders a happy path in pastel.

The version worth producing has three properties:

Current state, honestly. Including the steps that happen outside the product: the phone call, the spreadsheet, the person in the office who fixes it manually.
Emotional low points marked. Not because feelings are the point, but because that is where churn happens and where a small fix buys the most.
A future state that is a decision, not a wish. If the future-state map includes a capability nobody has committed to build, it is a pitch deck.

Where they pay off most is a build with many small paths rather than one big one — member portals, booking systems, anything with a renewal or an entitlement. On those, the map is usually what reveals that two flows people assumed were the same are not.

User stories

Stories are where research becomes buildable, and where most of the value leaks out.

A story is not a feature written in a costume. “As a user, I want a dashboard” tells a developer nothing that “build a dashboard” did not. The format only helps when the reason half is real, because that is what lets someone challenge the solution:

As a venue manager, I need to see which bookings are unconfirmed 48 hours out, so I can chase them before the kitchen orders stock.

That version can be argued with. Maybe it should not be a dashboard — maybe it should be an email at 48 hours. The story survives that argument; a feature request does not.

What makes stories usable:

Acceptance criteria that are testable. “Works well on mobile” is not. “Loads and is usable on a 360px viewport” is.
Sized against reality. A story that cannot be finished in a sprint is an epic wearing a disguise, and it will hide its own risk until late.
Written with someone who will build it. Stories written entirely by a designer and handed over are re-litigated in the first sprint anyway.

Prototypes

A prototype exists to be wrong cheaply.

The trap is polish. A prototype that looks finished gets feedback on the colour of the button; one that is deliberately rough gets feedback on whether the flow makes sense. Test the flow first with something ugly, then test the interface once the flow survives.

Two tests worth running before a build starts:

The unfamiliar user test. Someone who has never seen it attempts the primary task, unprompted. You are watching for where they stop, not what they say afterwards.
The edge case walk-through. Take the three states everyone forgets — empty, error, and “this account is different” — and check the design has an answer. Most do not, and they get invented under pressure during the build.

How much is enough

The honest answer is that it scales with how reversible the decision is.

A marketing site: a few days. The cost of getting it wrong is a redesign, not a rebuild.
A product with an existing user base: enough to talk to those users. They will tell you which of your assumptions is expensive.
A platform replacing an internal system: the most, and the most likely to be cut. These fail on the workflows nobody documented, which is precisely what research finds.

The failure mode is not too little research. It is research that happens, produces a deck, and does not change the backlog. If the stories going into the first sprint would have been the same without it, the phase did not happen — it was just observed.

Where this fits

Research and design work is most useful attached to a build, because the findings need somewhere to go. On its own it produces a document; alongside a team it produces a different product.

If you are weighing whether a discovery phase is worth it on a specific piece of work, that is the conversation we usually start with — and it is cheaper before the scope is fixed than after.