When a deadline is looming, discovery is often treated as the optional bit. The team has a feature request, a customer waiting and a plan that looks reassuringly full. Surely the sensible move is to start designing.
Sometimes it is. More often, the faster move is to spend a little time learning what problem you are actually solving. A week of useful discovery can prevent months of very efficient work on the wrong thing.
Discovery is not a long prelude
Good discovery is not a theatre production with endless sticky notes. It is a disciplined way to reduce uncertainty before making an expensive commitment. The GOV.UK guidance on moderated usability testing is refreshingly practical: test specific, believable tasks with actual or likely users, and use what you see to improve the service.
When time is tight, I start with three questions:
What decision are we trying to make?
What would make that decision less risky?
What is the smallest piece of evidence that could change our mind?
That keeps discovery focused. You do not need to learn everything about every user. You need enough evidence to choose a sensible next move.
Use the evidence you already have
Teams often assume research begins with recruitment. It can begin with support tickets, sales calls, implementation notes, product analytics and the people who work closest to customers. These sources are not a substitute for speaking to users, but they are excellent at identifying patterns worth testing.
At the start of a discovery cycle, I want to know where people abandon a task, what they repeatedly ask for help with, which workaround they have invented and which part of the workflow makes internal teams nervous. Those signals help turn a vague request into a testable hypothesis.
Prototype the risky part
A prototype is useful when it answers a question. It is less useful when it becomes a beautifully detailed way to avoid asking one. If the risk is whether users understand a new status model, test the status model. If the risk is whether they can compare two options, test the comparison. Do not spend three days animating a navigation transition that nobody has questioned.
The task matters as much as the prototype. GOV.UK recommends tasks that have a clear goal, feel believable and do not give away the answer. That is a good standard for any product team. “Tell me what you think” produces opinions. “You need to correct an invoice before approval, what would you do?” produces evidence.
Share what changed your mind
The most valuable output from discovery is not a slide deck. It is a visible change in the team’s understanding. Record the question, the evidence, the decision and what remains uncertain. This makes it easier for product, design and engineering to move together, and it stops old assumptions creeping back in during delivery.
Discovery does not need to slow a team down. It gives the team permission to move quickly with fewer blind spots. That is a better kind of speed.
