Discovery is the work of understanding a problem well enough to decide what to do next. Its job is to reduce uncertainty, not to produce deliverables.
Written as practical advice. Where a step rests on established research practice, the source is listed under References. Nothing here is a universal rule.
Write it down, with who has it and how you know. Expect to rewrite it.
Ask about goals, constraints, current process, known problems, risks, dependencies, earlier decisions and how they would measure success.
Past research, analytics, support tickets. Cheaper than new research and often overlooked.
Interviews and observation to learn about the problem, not to test a solution.
Including the parts users never see.
What people use today, including spreadsheets and workarounds.
Rank them by how wrong you could be and how much it would matter.
Weak
What features do you want?
Better
What would success look like a year from now?
Why. The first collects solutions. The second finds the goal behind them.
Weak
Do you agree users need this?
Better
What do you hear from users about this?
Why. Ask what they know, not whether they agree with you.
Senior designer note“Do not ask users to design the solution for you.”
References