Design Discovery Task¶
Discovery activity — instantiates Inquiry-Guided Exploration
A pre-solution investigation that forces a team to surface and suspend its assumptions about users, gather evidence about real needs, and reframe the problem before anyone designs an answer.
Teams jump to solutions. Design Discovery Task is the mechanism that inserts a disciplined investigation before solution design — its whole reason to exist is to delay the answer until the problem is understood. Its defining trait is the deliberate order of operations: first make the team's assumptions about users explicit (so they can be tested rather than acted on), then gather evidence about what users actually do and need, and only then produce a reframed problem statement or design brief. It is inquiry pointed at people and needs rather than at a natural phenomenon or a historical fact, and it succeeds precisely when it changes what the team thought the problem was. It does not vet source credibility with a formal filter, and it does not choose the solution; it produces the reframed problem the solution will answer.
Example¶
A SaaS company's product team is convinced they know why users abandon onboarding: "the sign-up form is too long." They are ready to cut fields. A design discovery task stops them first. The facilitator runs an assumption dump — everyone writes what they believe is driving abandonment, and the wall fills with confident guesses: form length, price shock, too many emails. Those beliefs are now on the table as hypotheses, not facts. That is the prior-knowledge probe, and it is the move that makes the rest honest.
Then the team gathers evidence: eight moderated interviews with recently-abandoned users, plus a replay of session recordings at the drop-off step. The evidence does not fit the assumption. Users are not quitting at the long form; they sail through it. They quit at step three, where the product asks them to connect a data source they do not yet have a reason to trust it with — abandonment is a confidence problem, not a length problem. The discovery task closes with a one-page reframe: not "shorten the form" but "earn permission before asking for the integration." That brief — the reframed problem — is the deliverable, and it points the eventual design somewhere the team would never have gone.
How it works¶
- Surface assumptions first. Before any research, the team makes its beliefs about users and causes explicit, converting private certainty into testable hypotheses.
- Gather evidence about behavior and need. Interviews, session replays, contextual observation, or support-ticket mining collect what users actually do — the tool matched to the kind of claim the team wants to make.
- Let the evidence contradict the plan. The task is working when the findings dislodge a starting assumption; a discovery that merely confirms the plan usually was not a discovery.
- Reframe, don't solve. The output is a restated problem or design brief, deliberately stopping short of the solution so the design space stays open.
Tuning parameters¶
- Assumption-surfacing depth — a quick sticky-note dump versus a structured assumptions map with confidence ratings. Deeper surfacing catches more hidden bias but costs time and can feel like navel-gazing.
- Evidence method — interviews, observation, analytics, or diary studies. Each sees a different slice of the user; the choice sets what kinds of need the task can detect.
- Reframe latitude — how far the brief is allowed to move from the original problem. Wide latitude finds bigger insights but can unsettle stakeholders expecting the assumed fix.
- Solution firewall — how strictly solution talk is deferred. A hard firewall protects the inquiry from premature solutioning but frustrates teams itching to build.
When it helps, and when it misleads¶
Its strength is that it attacks the most expensive error in design — building the right solution to the wrong problem — by spending a little investigation up front to reframe the question. It is the "discover" phase of the classic double-diamond model, where a team deliberately widens its understanding of the problem before narrowing to a definition.[n1] The assumption-surfacing step is what gives the evidence something to overturn.
Its failure mode is discovery that never disturbs the plan: the team runs interviews, hears what it expected, and proceeds with the fix it had already chosen — research theater that launders a decision instead of testing it. A related collapse is when the "discovery" degrades into a brainstorming session with no user evidence at all, producing enthusiasm and sticky notes but no grounded reframe. The guarding discipline is to force the assumptions onto the wall before the evidence arrives, so the team can see whether the findings actually moved them — and to hold the solution firewall until the reframe is written.
How it implements the components¶
Design Discovery Task realizes the archetype's problem-framing machinery — the investigation that precedes and shapes a solution:
prior_knowledge_probe— the assumption-surfacing step that makes the team's beliefs about users explicit and testable before any evidence is gathered.evidence_gathering_tool— the interviews, session replays, and observation protocols that collect what users actually do and need.synthesis_artifact— the reframed problem statement or design brief that consolidates the discovery into a usable, hand-off-able output.
It does NOT implement source_quality_filter or guidance_checkpoint — Design Discovery gathers user evidence but leaves formal credibility-grading of raw sources to its nearest twin Field Investigation (which shares the evidence-gathering tool but adds the provenance filter this task omits), and it runs no mid-course checkpoint rhythm — that is Discovery Learning with Checkpoints's.
Related¶
- Instantiates: Inquiry-Guided Exploration — Design Discovery is the archetype applied to users and needs before solution selection.
- Sibling mechanisms: Guided Research Question · Inquiry Project · Discovery Learning with Checkpoints · Field Investigation · Investigative Workshop · Problem-Based Learning Case · Synthesis Debrief · Evidence Log
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: Design Discovery Task operates as a bounded evaluation of existing evidence or work that produces a finding or disposition because it a pre-solution investigation that forces a team to surface and suspend its assumptions about users, gather evidence about real needs, and reframe the problem before anyone designs an answer.
Independent corroboration: The frozen evidence defines Design Discovery Task as 'A pre-solution investigation that forces a team to surface and suspend its assumptions about users, gather evidence about real needs, and reframe the problem before anyone designs an answer', so its operative form is Assessment, Review & Assurance.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Human-Computer Interaction
Origin pattern: Single lineage
Present-day reach: Multi-domain
Rationale: User-centered design cohered discovery-before-solution workflows that test assumptions about users and reframe the problem before ideation.
Related originating lineages:
- Ethnography & Qualitative Methods — Field inquiry and contextual observation supplied evidence-gathering about actual practice and need.
Review resolution: User-centered design cohered discovery-before-solution workflows that test assumptions about users and reframe the problem before ideation. The retained alternate lineages materially shaped the mechanism's form.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] The Double Diamond, a design-process model popularized by the British Design Council, splits work into two diamonds — Discover/Define, then Develop/Deliver — each opening wide before narrowing. Design Discovery Task is the first half of the first diamond: the deliberate divergence into understanding the problem, held open so the team does not narrow to a solution before it has reframed what it is solving. ↩