Most don’t fail because they were built badly - they were just built for the wrong problem. To countermand that, some bright sparks in the industry long ago defined a process to fix that.
UX Discovery is a structured research phase that usually happens before any design or development work even starts. The purpose is to understand what users actually need, why they need it, and how that determines the product roadmap. When done well, it’s the single most reliable way to protect development budgets from being spent on features no one’s going to use.
This guide covers what it is, how it reduces business risk, the step-by-step process, and which research methods produce the most useful outputs.
What is UX Discovery?
Put simply, UX Discovery is the phase of a project during which a product team investigates the real problem before committing to a solution. Combining user research, stakeholder alignment, and market analysis, it helps validate assumptions and define the product scope with evidence, rather than subjective opinion.
The word "discovery" signals the intent: you’re asking and answering, not arbitrarily deciding. The team doesn’t walk in with a predetermined solution and look for proof it will work. They walk in with questions and let the research generate answers.
Discovery typically runs two to four weeks for a focused feature and six to twelve weeks for a new product or platform - although with the increased use of AI tools in recent times, the actual timelines can end up being much shorter. It ends when the team can answer three questions with confidence:
- Who exactly is the user, and what’s the specific problem they face?
- What does a solution need to do to address that problem?
- Is the proposed solution technically and commercially viable?
If those three questions are still unanswered at the start of development, the team ends up building on assumptions - and from experience we can confidently say, some of those assumptions will be wrong.
Why UX Discovery protects your development budget.
Development is expensive. A mid-sized product team typically costs between €15,000 and €50,000 per month when you include salaries, tooling, and management. Spending two months of that kind of budget on a feature set that doesn’t answer what users need isn’t even a technical failure - it’s a planning failure.
A well-structured discovery process addresses this by front-loading the cheap work. Research interviews cost a fraction of engineering time. Mapping a user journey costs a fraction of building the wrong one. Validating a concept with a prototype costs a fraction of developing the full product.
The ROI case is straightforward: a six-week discovery engagement that surfaces a fundamental flaw in product assumptions can prevent months of development in the wrong direction. It also exposes what the right direction is, meaning the development phase gets faster and more focused. That tends to happen when the team knows what they’re building and why.
Companies that skip discovery often end up in a second cycle: ship the product, watch the disappointing metrics mount, commission user research to find out what went wrong, and then rebuild. And ultimately, that second cycle costs more than any discovery might have. There’s a reason why brands like Amazon invest 100x more into UX than advertising.
Then there’s the risk-reduction dimension, extending beyond budget considerations. Discovery surfaces misalignment between stakeholders earlier, when it’s still cheaper and easier to resolve. Instead of more debates about what users want that will inevitably be biased based on context, you get actual user data to work from. From that, you create a documented rationale for product decisions that protects the team when priorities shift several months later.
The process: step by step.
One of the most useful frameworks for understanding discovery is the Double Diamond, developed by the British Design Council. In it, the process is mapped as two connected diamonds: the first expands to explore the problem space, then contracts to define the right problem. The second expands to explore solutions, then contracts to deliver the most relevant ones. UX Discovery covers the entire first diamond and the opening of the second.
Step 1: stakeholder mapping and alignment.
Before you even start with any external research, your team needs to understand and visualize who inside the organization has a stake in the product, and reconcile what they believe about the users versus where those beliefs have a conflict.
A stakeholder map identifies every person whose priorities affect the product, organized by their influence and their level of involvement in the process. Through a structured alignment session, you can then surface the assumptions each stakeholder carries, what goals they’re optimizing for, and any constraints the product has to work within.
This step is crucial. Discovery research might challenge some of these assumptions and bring up uncomfortable truths. If stakeholders aren’t aligned to start, the research findings risk becoming a political document rather than a shared foundation. Getting the assumptions down on paper before the research begins makes it much easier for teams to use any findings or conclusions constructively.
Step 2: user research planning.
The product design and research team defines who needs to be interviewed, what they need to learn, and which research methods fit the questions that have to be asked. Not all discovery projects need every method of gathering data - so the choice depends on what you already know, don’t know, and what the stakes of inaccuracy or error are.
Within a research plan, you state the primary research questions, target user segments, selected methods, participant number, and of course, the timeline. That way, the team stays focused during fieldwork and it’s easier to explain the findings to stakeholders.
Step 3: qualitative research fieldwork.
This is where the magic happens - the actual user research. Methods vary, but the objective is the same: understanding the user’s situation, goals, frustrations, and behaviors to enough of a degree that you can make confident design decisions.
In-depth interviews
What’s the backbone of most research projects? One-on-one conversations. User interviews make up a crucial part of discovery projects, with a skilled interviewer running 45-75 minute sessions that explore the user’s context, current workarounds, decision-making process, and unmet needs.
The output isn’t a list of feature requests. Most of the time, users don’t actually know what they want from a product - but they know what they struggle with and what a perfect world might look like for them. So the output ends up being a detailed picture of a problem they’re trying to solve, which the design team can draw from to generate and evaluate solutions.
Depending on product scale, it’s best to aim for 8-12 interviews per distinct user segment. You’ll start to see patterns around that number, and adding a ton of extra interviews past the point of saturation rarely changes the conclusions in any significant way.
Competitive and Market Audit
Understanding the alternatives that exist in the market at the time, and how users are solving the problem on their own is as important as understanding the problem itself. The audit helps to cover direct competitors, indirect competitors (adjacent tools or products the users are already engaging with), and any workarounds users build on their own.
A structured audit reviews each competitor across four dimensions: target audience, core feature set, pricing model, and the gaps users learn to work around. It’s in the last category where product opportunities tend to live. Ultimately, what you get is a landscape map that shows you what exists, and where your product could differentiate, alongside a set of positioning insights the product team can lean on.
Step 4: synthesis and insight development.
Raw research data is just noise. Synthesis turns it into signal.
The team reviews all interview notes and observations, groups related findings by theme, and extracts patterns that appear across multiple participants. The way you test a real insight is by asking whether it changes a product decision - if the finding is interesting, but wouldn’t change the product, then it’s not really an insight.
Synthesis sessions work best when the full project team is there. Designers, developers, and product managers all interpret data according to their perspective, and those interpretations produce stronger insights than any single discipline can generate independently.
A useful synthesis output is a "how might we" list: short problem statements framed as opportunities rather than solutions. "How might we help operations managers export their weekly report in under two minutes?" is a better input to design than "users want faster exports." The framing keeps the team focused on the specific user need while leaving the solution space open for inputs.
After synthesis, the team should be able to write two or three crisp insight statements that a non-researcher can understand and that would change at least one product decision. If the insights are too vague to change a decision, that means you’ve got more synthesis to do.
Step 5: deliverable development.
Discovery produces three core deliverables that carry the research findings into the design and development phases.
User personas
A persona is a documented profile of a real user type, built from research rather than invented from thin air. Each persona describes the user's goals, daily context, key frustrations, and the criteria they use to evaluate solutions.
Personas give the team a concrete point of reference when making design decisions. Instead of debating what "the user" wants in the abstract, the team asks what a specific persona needs in a specific situation. For this reason, personas are often named and take on a life of their own for the purposes of the research project.
Well-built personas have three to five representative quotes from actual interviews, a concise problem statement, and a summary of the conditions that would make this user switch to - or away - from the product.
User journey maps
Journey maps trace the steps a user takes to accomplish a goal, from first awareness of the problem through to resolution. They capture what people might do at each stage, what they think and feel, and where they encounter speed bumps or irritants.
By drawing a journey map, you make bottlenecks visible. The most valuable output often isn’t the set of stages where users struggle most, but those where they give up completely. Those exits are a clear representation of lost revenue - with a clear address.
Validated product backlog
The research findings translate into product requirements through a validated backlog. The team sizes them up, prioritizes, and labels each item with the assumption it rests on, so everyone knows what to test first and why.
The validated backlog is the document that carries discovery into development. It replaces a wish list with a ranked set of bets, each with an evidence base.
UX Discovery in practice: Widelab client work.
We’ve seen it in every industry. Teams skip discovery and build confident products that try to solve the wrong problem. The ones that invest in good discovery build less, ship quick, and waste far less of the development budget in the end.
At Widelab, we’ve run countless product discovery engagements across SaaS, healthcare, and consumer platforms. A few examples of our work:
AddEvent needed to understand how event organizers and their attendees were using the platform before committing to a major redesign. Widelab ran structured user research and testing sessions, producing findings that directly shaped which flows to rebuild and which to leave alone. The research output was a presentation of tested results tied to specific UI decisions, not a general report - and it enabled us to act quickly and with confidence in the final result.
PeerPal and Medcase both came to discovery at the new-product stage, before any significant development had started. For each, Widelab ran a full discovery workshop covering stakeholder alignment, user needs mapping, and MVP prioritization. The output was an interactive board with flows and a complete knowledge base, alongside lower-fidelity designs for the concepts that needed visual grounding to discuss productively.
LSM Apps used the workshop to align a cross-functional team around a product scope that had grown unwieldy. The discovery process forced explicit prioritization decisions that the team had been deferring, ultimately giving a much clearer picture of what the core value of the product was.
In each case, the research project produced the same three things: a shared definition of the user, a validated problem statement, and a scoped backlog the development team could act on immediately. The format of the output was different each time - but the clarity it created was the same.
A starting framework for better discovery work.
As we at Widelab like to say, starting often feels like the hard part. If you’re looking for a partner who can take you through the process from start to finish, you know where to find us.
In the meantime, these are the key starting points. Adapt them to your project needs and the stage you’re at.
Stakeholder map: List every stakeholder, their role, their primary goal for the product, and the one assumption they hold most strongly about the user.
Interview guide structure: Open with context questions (tell me about your current process), move to behavior questions (walk me through the last time you...), close with priority questions (if you could change one thing about this, what would it be). Don’t ask what features they want - they probably don’t quite know the answer but they might be compelled to answer anyway.
Persona template: Name and role / Key goal / Current workflow / Primary frustration / Decision criteria / Representative quote.
Journey map columns: Stage / User action / User thought / User emotion / Pain point / Opportunity.
Backlog item format: As a [persona], I need to [action] so that [outcome]. Priority: [1-3]. Evidence: [interview finding or observation]. Assumption to test: [what we are not yet certain of].
FAQ
How long does a UX Discovery engagement take?
For a new product or a significant platform change, plan for six to twelve weeks. For a focused feature or module, four to six weeks is typical. Shorter engagements are possible for narrowly scoped questions, or when working with AI tools to expedite certain processes, but be wary of anything under 1-2 weeks. It’s better to take the extra week instead of paying for the extra 3 months of development.
What’s the difference between UX Discovery and UX research?
The first is a project phase. UX research is a collection of methods. Discovery uses UX research methods alongside product strategy and stakeholder alignment work. UX research can happen at any point in a product lifecycle; discovery is specifically the front-end phase before design and development begin.
Do we need discovery if we already know our users well?
The teams that know their users best from direct experience still benefit from discovery because they need to document that knowledge, align stakeholders around it, and translate it into a prioritized scope. Familiarity can also lead to opacity - discovery challenges the assumptions that make it difficult to see the truth with clarity.
What happens if discovery finds our idea is wrong?
That’s the best possible outcome. It means the discovery saved the development budget that would’ve been spent on the wrong product. The research will also have generated enough understanding of the real problem to point toward a better direction - which ultimately benefits you, your product, and your users.
How do we know when discovery is complete?
Discovery is complete when the team can define the user, the problem, and the intended solution with enough specificity that two developers who weren’t part of the research sessions could build to the same brief independently. If the brief still requires interpretation, the scope isn’t tight enough yet.
The next step.
UX Discovery isn’t a ‘formality’ that precedes real product work. It’s what makes everything that comes after it more likely to succeed. Personas, journey maps, validated backlog - it’s not just empty documentation you’ll file away on a shelf forever. That’s where the decisions live.
If you’re looking at building a new product or redesigning an existing one, a solid product discovery workshop with a trusted partner is where you start. Our workshops run over two focused days and produce a prioritized problem definition, initial persona set, and a validated scope that your development team can act on immediately.
Book a meeting to define your product scope and figure out what you’re building - before you start building it.
