What should ux discovery phase deliverables include?

I expect ux discovery phase deliverables to include a decision brief, an evidence-backed problem definition, a prioritised risk register and a recommendation for what to test, build or stop. Maps, personas and presentations belong in that set only when they help make those decisions.

Start with a discovery brief that names the decision

I start with a one-page brief, not a research schedule. It names the decision discovery must inform, who can make it, the deadline and the constraints that could rule out an option. “Understand our customers” isn't a useful brief. “Decide whether to replace the manual approval step before the next contract renewal” gives the work a boundary. It also makes stopping possible.

Nielsen Norman Group describes discovery as work that clarifies the problem, the people affected and the surrounding context before committing to solutions. I translate that into a practical constraint: the brief must leave room for the answer to be “don't build this”. If the team has already promised a particular feature, I record that commitment explicitly rather than pretending the solution is still open.

For a hypothetical approval service, I'd name the affected roles, the current workaround and the consequence of leaving things alone. I'd also separate fixed constraints from preferences. A contractual retention requirement may be fixed; a stakeholder's preferred dashboard layout isn't. The useful output is agreement about which decision needs evidence, not agreement about what the eventual screens should look like.

Build an evidence log and an assumption register

I keep observations separate from interpretations. An evidence log records the source, date, context and limitations of each finding. A support ticket about an abandoned application tells me something different from watching someone abandon it. Neither automatically explains how widespread the problem is. Where access permits, I link back to notes or recordings so another person can inspect the reasoning rather than trust my summary.

The assumption register records what must be true for a proposal to work. For an approval service, that might include applicants having the required documents, reviewers trusting submitted information and operations accepting a shorter review window. I rank assumptions by the damage caused if they're wrong and how little evidence supports them. The riskiest assumption isn't necessarily the one people mention most often.

Each high-risk assumption gets a next test and an owner. If reviewers won't accept the proposed evidence, I'd investigate that before refining the upload interaction. I don't assign precise confidence percentages to thin qualitative evidence. I use plain descriptions such as “observed in three sessions, not checked with occasional users”. That wording carries both the finding and its boundary into the decision meeting.

Use journey maps and personas only when they explain a problem

I make a journey map when the sequence of events matters to the decision. Waiting, handovers, repeated entry and work outside the product are useful things to expose. A map of an approval process should show where an application stops, who can restart it and what information they need. A row of cheerful and unhappy faces won't explain why the queue keeps growing.

I attach evidence to consequential steps and mark gaps visibly. If I haven't spoken to the person handling exceptions, that part of the map remains uncertain. I don't fill it with a plausible story to make the artefact look complete. The map earns its place when it changes the proposed intervention, perhaps from a new applicant screen to better routing for reviewers.

I apply the same test to personas. Differences in behaviour, access, responsibility or frequency of use can change a design decision. Invented names, portraits and favourite brands usually can't. For a service used daily by administrators and twice a year by applicants, a short comparison of tasks and constraints may be enough. I'd skip the persona deck unless it resolves a disagreement that affects the scope.

Prioritise problems before turning them into features

I write each candidate problem with an affected group, a situation, an observed difficulty and a consequence. “Applicants can't tell which evidence is missing, so they resubmit unchanged documents” is testable. “We need a smarter portal” isn't a problem statement. The distinction matters because a feature-shaped statement quietly removes cheaper alternatives before anyone has compared them, including changes to instructions, policy or staffing.

Ideo's design thinking framework considers people's needs alongside technical feasibility and business viability. I use those as different checks, not as interchangeable points in a score. A serious user problem can still be a poor investment if the organisation cannot operate the proposed service. Equally, a commercially attractive idea doesn't become useful merely because the team can deliver it quickly.

For prioritisation, I compare the severity of the consequence, available evidence about reach, the current workaround and the cost of delay. Unknown reach stays unknown; three interviews don't establish a market percentage. I then recommend one problem to pursue and explain why the others can wait. If two options remain close, the deliverable should name the evidence that would separate them, not disguise the uncertainty with decimal scores.

Document feasibility risks and define success measures

I bring engineering and operations into discovery before recommending a direction. A concept can be clear to users and still depend on unavailable data, slow approval rules or an unsupported integration. The useful deliverable is a constraint and risk note: what has been checked, what remains uncertain and which uncertainty could invalidate the recommendation. I don't ask for production architecture just to answer a feasibility question.

A narrow technical test may be enough. For an approval service, I'd ask whether the existing system can expose application status at the required frequency and whether those statuses mean anything useful to applicants. A successful connection alone wouldn't settle both questions. I'd also check who maintains the information and what happens when it is missing, delayed or wrong. Those failures become part of the proposed scope.

I define success before discussing visual polish. Possible measures include repeat submissions, avoidable support contacts and elapsed time between submission and a valid decision. Each needs a definition, a baseline source and an owner. I'd pair faster processing with a guardrail such as incorrect approvals, so speed doesn't hide harm. If reliable baseline data doesn't exist, establishing it becomes an explicit next step rather than an invented target.

End discovery with a recommendation and a next test

I finish with a short decision record supported by the underlying evidence. It states the recommended direction, alternatives considered, remaining risks and the commitment being requested. That commitment might be a prototype test, a limited operational trial or implementation of a small change. It shouldn't automatically be permission to build everything discussed during discovery. The size of the commitment should match the strength of the evidence.

I make the next step specific enough to schedule. Rather than “validate the concept”, I'd propose testing whether occasional applicants can identify missing evidence from a sample status message, then checking whether reviewers can maintain those messages during normal work. I name the owner, required access and what result would make me reconsider. A test without a consequence for the decision is just another activity.

For handover, I keep the brief, evidence, recommendation and unresolved questions easy to find. I remove duplicate slides and diagrams that no longer affect a choice. Discovery is ready to close when the decision owner can make the next bounded commitment with the uncertainties visible. If access restrictions or contradictory evidence prevent that, I recommend a targeted extension and explain exactly which decision it would enable.

Questions people ask

What are the main ux discovery phase deliverables?

I expect a decision brief, a problem definition linked to evidence, prioritised assumptions and a recommendation with success measures. I add maps, prototypes or technical findings when they resolve a specific uncertainty.

How long should a ux discovery phase take?

I timebox discovery around the decision, access to participants and the cost of getting it wrong. A narrow workflow question may need less investigation than a service involving several teams, legal constraints and unfamiliar technology.

Are personas required during discovery?

I don't treat personas as mandatory. I use them when meaningful differences between groups affect priorities or design choices; otherwise, a concise description of roles, behaviours and constraints is enough.

Should discovery include wireframes or prototypes?

I include them when making an idea tangible helps test a consequential assumption. I avoid detailed screens when the unresolved question concerns demand, policy or data access, because interface refinement won't answer it.

Where I checked my thinking

• Nielsen Norman Group: Discovery, building the right thing
• Ideo: Design thinking