How to Build a Focused UX Discovery Plan Around a Decision
The request sounds familiar:
Can you do some discovery to validate the new review step before the next roadmap meeting? We probably need a few interviews and a workshop.
The team has named a preferred direction, two activities, and a deadline, but not the decision the work must inform. It has not explained what could change, which uncertainty matters, who must participate, or what would cause the team to stop or revise.
Discovery can then become a collection of reasonable activities that produces an interesting readout but no clear movement.
A focused UX discovery plan works backward from a human decision. It identifies the uncertainty that could materially affect that decision, chooses the lightest responsible way to investigate it, and makes the limits of the resulting evidence explicit.
Why “validate the idea” is not a discovery goal
“Validate” often sounds rigorous, but it can quietly bias the assignment.
If the goal is to validate a new review step, the team has implied the desired result. The work may be shaped around confirming the step instead of learning whether it addresses the problem, introduces friction, or should exist.
Compare these two goals:
Confirmation goal: Validate that administrators need a dedicated review step before applying a bulk role change.
Learning goal: Understand what administrators need to know before applying a bulk role change, where uncertainty occurs, and whether an inline summary, a dedicated review step, a different treatment, or no change best supports the decision.
The second goal preserves more outcomes: advance the step, choose another direction, revise the framing, gather more evidence, or select neither.
Useful discovery reduces uncertainty. It does not guarantee support for the current idea.
Start with the decision, not the method
Before scheduling interviews, workshops, surveys, or usability sessions, write the decision in one sentence:
By [date], [decision owner] will decide whether to [choose, change, narrow, sequence, pause, or reject a course of action] based on [the confirmed criteria].
For example:
By August 31, the product decision owner will decide whether Concept A, Concept B, neither concept, or a revised direction should advance to final design and implementation planning.
This statement defines four things:
- It defines what can change.
- It names the person who owns the decision.
- It creates a time boundary.
- It prevents discovery from becoming a general search for interesting information.
If the decision or owner is unknown, the purpose remains unresolved. You may draft a plan for confirmation, but it is not ready to run.
Separate existing evidence, assumptions, and gaps
Review credible existing evidence first, then preserve what each source can and cannot support. Use five labels:
| Label | Use it when |
|---|---|
| Confirmed | A statement is explicitly supported by a supplied source or documented human confirmation. |
| Assumption | The team believes the statement may be true, but it has not been verified. |
| Inference | The statement is a reasoned interpretation of the available inputs. |
| Gap | Important information is missing, unclear, outdated, or conflicting. |
| Recommendation | A reversible next step is proposed for human consideration. |
Suppose 18 support tickets mention uncertainty about selected members, role changes, or save states. A support summary can confirm the count and justify investigation. It cannot establish prevalence, root cause, affected-customer count, or the right treatment.
Evidence labels keep directional signals useful without asking them to prove more than they can.
Build a Decision-to-Learning Map
Once the decision and evidence boundaries are visible, create a four-column map:
| Decision | Uncertainty that matters | Evidence needed | Lightest responsible method |
|---|---|---|---|
| What must a person decide? | What could materially change that decision? | What would reduce that uncertainty? | What is the least burdensome credible way to obtain it? |
Limit the primary map to five rows. This is a focus rule, not a universal standard. If a question cannot change the decision, scope, risk, or next action, move or remove it.
| Weak learning question | Stronger learning question |
|---|---|
| Do users like Concept B? | Can administrators predict who will be affected and what will change before they confirm the action in each concept? |
| Is the new flow intuitive? | Where do administrators hesitate, make an error, or seek additional information while completing the bulk role-change task? |
| Which concept is better? | What critical comprehension, interaction, accessibility, or feasibility issues would prevent either concept from advancing? |
Stronger questions name observable behavior, a specific uncertainty, or a decision-relevant risk while preserving “neither” as an outcome.
Match each question to the lightest responsible method
Select a method because it can address a specific learning question within the real constraints, not because it is familiar or already scheduled.
| If you need to learn about | A method that may fit | What it cannot establish by itself |
|---|---|---|
| Prior signals, decisions, or known constraints | Existing-evidence or artifact review | Current user behavior or prevalence beyond the source |
| Goals, context, workarounds, or mental models | Interviews or contextual inquiry with relevant participants | Statistical prevalence or concept usability without an interaction task |
| Interaction with a current experience or testable concept | Evaluative usability sessions | Market demand, population preference, or business impact |
| Scale, frequency, or behavioral patterns | Appropriate analytics, logs, surveys, or experiments with qualified support | Root cause or lived context without additional interpretation |
| Feasibility, accessibility, policy, or system constraints | Technical, accessibility, policy, or process review | The affected user’s experience unless users are also included appropriately |
A method mismatch creates activity with weak decision value. A stakeholder workshop can clarify business constraints but cannot show how an administrator uses a prototype. Five usability sessions can reveal breakdowns in tested tasks but not statistical preference across the customer base. User interviews can explain context but not production effort.
Pair every method with what it cannot prove.
Define participants, access, inclusion, and required review
“Talk to five users” is not a participant plan.
Define the behavior or context that makes a participant relevant to the decision. Then confirm:
- Who the affected users are
- Which behaviors or situations matter
- How recruitment access will be obtained
- Who owns recruitment and facilitation
- What consent, privacy, recording, incentive, and data-handling rules apply
- How accommodation needs will be identified and supported
- Which research, accessibility, legal, security, or ethics reviews are required
- What the team will do if access is limited or unavailable
Stakeholders, subject-matter experts, employees, and other proxies may provide useful organizational context. They are not automatically substitutes for affected users.
If affected users cannot be included, state what the proxy can answer and what remains unknown. Do not relabel internal feedback as user validation.
Set milestones, stopping conditions, and a synthesis plan
A calendar is not enough. Every activity needs an entry condition, owner, output, and stopping or escalation rule.
Useful stopping conditions might include:
- Pause sessions if the prototypes do not present equivalent task information.
- Do not begin recruitment until the approved consent and data-handling process is confirmed.
- Stop testing an affected path if a critical accessibility issue makes the task unusable.
- Move or narrow the decision if the required participant access or feasibility input is not available by the decision date.
- Select neither concept if both fail the agreed minimum conditions.
Define synthesis before collection begins. Decide how you will separate observed behavior, participant statements, researcher interpretation, accessibility findings, engineering input, and team recommendations. Preserve contradictions and outliers. Do not turn comment counts into votes unless the study was explicitly designed and qualified to support that interpretation.
The plan should also state which claims the evidence may support and which claims it must not support.
Composite example: A decision-first discovery plan
Example note: The following company, people, product, dates, and evidence are fictional. The scenario is a composite created to demonstrate the method, not a customer result.
Maya, a senior product designer at a business-to-business software company, is working on a bulk role-assignment experience. A confirmed brief identifies uncertainty about selected members, the effect of the role change, and whether the change was saved. The team has two feasible prototype directions and a preference for the more explicit option, but no concept has been approved.
The decision is:
On August 31, the product decision owner will decide whether Concept A, Concept B, neither concept, or a revised direction should advance.
The evidence includes a directional support summary, a prior study that did not test either concept, a code-freeze date, and approved access to five enterprise administrators. It supports investigation, not prevalence or concept validation.
Maya creates this Decision-to-Learning Map:
| Decision | Uncertainty that matters | Evidence needed | Lightest responsible method |
|---|---|---|---|
| Advance A, B, neither, or revise | Can administrators identify who will be affected before applying the role? | Observed task behavior and participant explanation | Counterbalanced moderated usability tasks |
| Advance A, B, neither, or revise | Can administrators predict the role change and its effect? | Observed comprehension in equivalent scenarios | Usability tasks with neutral follow-up questions |
| Advance A, B, neither, or revise | Do administrators recognize successful completion? | Completion behavior, uncertainty, and repeat actions | Observed completion task using consistent success states |
| Advance A, B, neither, or revise | Does either direction contain a critical accessibility or feasibility barrier? | Qualified reviews and documented constraints | Accessibility review plus comparative engineering review |
The plan reviews existing evidence, clears both prototypes for keyboard and screen-reader use, pilots the script, runs the approved sessions, and combines bounded observations with accessibility and engineering findings.
The plan does not force a winner. If access fails, concepts are not comparable, or critical input is missing, the team pauses, revises, selects neither, or moves the decision.
The evidence may describe what five participants did and understood in the tasks. It cannot support claims of population preference, prevalence, demand, causality, or release impact.
Know when the plan is not ready to run
Imagine that the team wants interviews with customers next week, but no one has confirmed recruitment access, consent, recording, compensation, data handling, accommodation planning, or the required research review. The designer is also being asked to paste identifiable customer information into an AI tool that has not been approved by the organization.
That plan is not ready to run.
Depending on the severity of the gaps, it should remain Blocked or Ready for plan confirmation. The team should use the approved environment, minimize the information shared, involve the accountable research and governance partners, and document the minimum conditions before contacting participants or collecting evidence. Use three readiness states:
| State | Meaning |
|---|---|
| Blocked | A critical problem, decision, owner, access, policy, ethical, safety, feasibility, or evidence issue prevents responsible planning or execution. |
| Ready for plan confirmation | The draft is coherent enough for human review, but the framing, methods, participants, ownership, timing, or required reviews still need confirmation. |
| Ready to run | Qualified people approved the plan, the decision owner is confirmed, access is feasible, required reviews are complete, and approval is documented. |
An AI-generated plan cannot move itself to Ready to run. That status requires accountable human review and a record of approval.
Where AI can help, and where it must stop
AI may help organize supplied evidence, separate assumptions from confirmed information, identify contradictions, draft learning questions, compare possible methods, expose missing owners, and format a reviewable plan.
It must not:
- Invent participants, access, findings, quotes, behaviors, metrics, dates, owners, policies, or approvals
- Generate synthetic responses and present them as research evidence
- Choose the organization’s business priority or decision criteria
- Select participants or methods without qualified human review
- Treat stakeholders, experts, employees, or synthetic users as equivalent substitutes for affected users
- Turn qualitative observations into claims of prevalence, causality, statistical significance, or market demand
- Approve consent, privacy, accessibility, research, legal, security, or ethics requirements
- Declare the plan Ready to run based on its own confidence
Use AI-generated personas, quotes, responses, or themes only for clearly labeled rehearsal when appropriate, never as validation. Keep access to the original sources and verify every material claim before the plan is used.
Turn the map into a repeatable workflow
The Decision-to-Learning Map gives you a focused starting point. A repeatable system becomes more useful when evidence is fragmented, several methods are possible, participant access is constrained, or the work must pass multiple reviews before it begins.
Workflow 2 inside DesignMinder™ turns a reviewed brief, source-labeled evidence, assumptions, participant access, constraints, and decision rights into a complete discovery frame and plan. It adds the required-input template, copy-paste prompt, focused learning agenda, activity plan, participant and evidence requirements, synthesis approach, milestones, risks, readiness gate, confirmation message, human-review checklist, failure conditions, and completed example.
It is part of the DesignMinder AI Operations Starter Kit for Designers, a six-workflow system for the work around design. AI drafts the structure. Qualified people approve the method, protect participants, interpret the evidence, and make the decision.
Founding Edition: $49.99. Instant digital download for one named individual. ChatGPT access is not included. Outputs are drafts and require human review. All sales are final and non-refundable, except where required by applicable law.
Frequently asked questions
What is a UX discovery plan?
A UX discovery plan connects a problem, users, evidence, assumptions, questions, methods, participants, constraints, milestones, synthesis, and a named human decision. It makes the learning effort bounded and reviewable.
What should a focused discovery plan include?
At minimum, include the decision and owner, discovery goal, evidence and uncertainty map, prioritized learning questions, justified methods, participant or evidence requirements, responsible-use requirements, roles, timing, outputs, method limitations, stopping conditions, synthesis plan, and readiness state.
How many discovery questions should a plan have?
For this method, use three to five decision-relevant questions and park the rest. The limit is a focus rule, not a universal research standard. Other scopes may require a different structure.
How do I choose the right discovery method?
Start with the decision and uncertainty, then choose the lightest responsible method that can produce the needed evidence. Confirm access, expertise, governance, and feasibility, and state what the method cannot establish.
Can AI create a UX discovery plan?
AI can organize supplied inputs, expose gaps, draft questions, and suggest a reviewable structure. It cannot create valid findings, approve methods, select business priorities, authorize participant contact, complete required reviews, or declare the plan ready. Qualified people must verify and approve the plan.