Most products 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 research phase, structured to determine what users actually need, why, and how that influences the roadmap of the product. It usually happens before you start on design or development work. If you do it well, it's the most foolproof way to protect your dev budget; so you don't end up spending money on features that no one will use.
In this guide we'll talk about what it is, the ways in which it reduces risk to a business, step-by-step process, and which research methods produce the best outputs for designers to act on.
What is UX Discovery?
In simple terms, UX Discovery is the phase when a product team investigates and determines the real problem the product is trying to solve - before committing to a solution. That means doing user research, stakeholder alignment, marketing analysis, and more, to validate any assumptions and define the final product scope using evidence. It ensures that subjective opinion doesn't run the project.
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.
With a structured and efficient discovery process, you focus more effort on the cheaper work before dedicating time and resources to the expensive stuff. Engineering time is much more expensive than running several user interviews; just like mapping a user journey is a fraction of the time that it takes to write code or develop product. Prototypes are more cost-effective than developing a full-scale product from the get-go.
It's also a win in terms of ROI: a six-week discovery engagement that reveals fundamental flaws in product assumptions prevents months of development in the wrong direction. Not only that, it exposes what the right direction actually is, so the development phase runs much faster and more focused; which tends to happen if the team is clear on what they're building and why.
When companies skip discovery, they often end up in a second cycle of shipping the product, watching the metrics turn to disappointing, then ordering user research to figure out what went wrong, and rebuilding. The second cycle probably costs more than any discovery would have. There’s a reason why brands like Amazon invest 100x more into UX than advertising.
Then there’s risk-reduction, which goes beyond budget issues. Discovery reveals 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.
Stakeholder maps identify everyone who has a stake in the product and their priorities, plus how those might affect the product itself. They're organized by influences and involvement level in the whole process. By running a structured session for alignment, you surface the assumptions stakeholders have; what goals they're optimizing for; and constraints to plan around.
This step is really 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 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.
The user research is where the magic happens. Methods are very different from industry to designer to scope, but the goal is the same: understand the user. What is their situation, their goals, frustrations, behaviors? Get enough of a comprehension so you can confidently make 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 any alternative options that exist in the market and how users are solving the problem on their own is as important as understanding the problem. Competitive and market audits cover direct competitors, indirect competitors (similar tools or products that users are already committed to), and any workarounds users find on their own.
A structured audit checks each competitor across four criteria: target audience, core feature set, pricing model, and the gaps users learn to work around. The last category tends to be where product opportunities live. Ultimately, you get a landscape map that shows you what's already out there, and where your product could differentiate -alongside a set of insights the product team can lean on to improve positioning.
Step 4: synthesis and insight development.
Raw research data is 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 relevant.
Synthesis sessions needs the full project team to be there: designers, developers, and product managers all interpret data from their own 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. You construct it based on research and data, not subjective feeling. And each persona describes a user's goals, daily context, frustrations, and how they evaluate the best solutions for them.
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.
Drawing a journey map makes bottlenecks visible, and the most valuable output often isn't the series of stages where users struggle most; it's there 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.
.png)
