A new product often arrives as a list: a dashboard, accounts, notifications, perhaps an AI assistant. These are recognizable pieces of software, so they make an idea feel concrete. Yet the list can be detailed while the purpose remains vague. Before drawing screens, we want a sentence about the person who will use them.
That sentence needs a situation and a change. Imagine an independent designer who sends work to clients for approval. “Manage projects” is too broad to guide a first release. “Help a client approve the right version without searching an email thread” gives us something we can examine. We can ask what happens today, where uncertainty enters and what counts as finishing.
Follow the existing work
Begin with the last real instance of the task, if one is available. Ask someone to show the files, messages and decisions involved, with private details removed. Listen for the sequence rather than asking them to invent a better application. What triggered the task? What information did they need? Where did they stop and wait?
For our hypothetical designer, the obstacle might be version confusion, unclear authority or feedback arriving in several places. Those are different problems. A polished approval button will not resolve uncertainty about who can approve. Discovery should change what we intend to build when the evidence points somewhere else.
Write down what is observed separately from what is assumed. “Clients receive several file links” describes an observation. “A single portal will make them respond sooner” remains a hypothesis. Keeping that distinction visible helps a proposal explain both the work and what the work is expected to teach us.
Draw one complete journey
Choose the smallest journey that ends in a useful outcome. In the approval example, the designer shares a version, the client understands what needs reviewing, and a decision becomes visible to both people. The journey includes an unclear response, an expired link or a replaced file if those cases prevent completion.
This is a more useful scope boundary than a count of screens. A dashboard with ten widgets can still leave the central task unfinished. A short flow can be substantial if it handles the information, permissions and feedback needed to finish the work. Completeness belongs to the journey.
A rough sketch is enough to test the sequence. Walk through it using a plausible file and a specific request. Ask the reviewer to explain what they think happens next. If the sketch needs a spoken explanation at every step, writing production code is unlikely to settle the underlying question.
Make the first release answer something
A first release should have a question attached to it. Can a client distinguish the current version? Can the designer see which work is waiting for a decision? These questions suggest useful observation without forcing a large analytics project into the initial scope.
Keep a separate list of appealing additions. Notifications, history and richer branding may matter, but each should earn its place through the journey it supports. Deferring an idea is easier when the reason is recorded and there is a condition for revisiting it.
The output of discovery can be modest: a description of the user, the current task, one proposed journey, unresolved assumptions and an explicit boundary. That is enough to make a first feature purposeful. It also gives everyone a shared reference when the next good idea arrives.