A practical discovery phase before you build

Name the uncertainty you need to resolve

A discovery phase becomes useful when it answers a question that would otherwise make development a guess. Perhaps you do not know which user group needs the product most, whether a workflow requires an integration or whether people understand a proposed interaction.

Write down that uncertainty and the decision it affects. A workshop or prototype then has a clear purpose. Without it, discovery can become a set of attractive deliverables that do not change what the team plans to build.

Gather evidence around real tasks

Talk to people who perform the workflow today. Ask them to describe their last attempt rather than an ideal future process. Where possible, observe the tools, handoffs and workarounds involved.

Use a prototype to test the parts of the journey that are still uncertain. Keep the prototype focused enough that a person can attempt the important task without an explanation from the designer. Record where they hesitate and what they expect to happen next.

Turn findings into a release boundary

A first release needs both a list of included behaviours and a list of things it will defer. Explain what the chosen scope lets the user accomplish. Then identify dependencies, such as account permissions, data quality or an external system that must be ready.

Resolve the riskiest technical dependency with a small experiment before treating the delivery estimate as reliable. A product decision and a technical assumption should not quietly become the same thing.

• A shared problem statement and intended user group.
• One end-to-end journey for the first release.
• A record of decisions, assumptions and unresolved questions.
• Acceptance criteria and a practical delivery sequence.

Keep discovery connected to delivery

Bring design and engineering into the discussion before the handover. Review whether the proposed flow can handle empty states, errors and permissions as well as the ideal path.

Revisit the discovery decisions when you learn from a working product. A scope document is a starting point, not a reason to ignore new evidence. The most useful outcome is a team that understands the same problem and can make the next decision together.