A request for a new portal may actually be a request for fewer status calls, faster approvals, or clearer ownership. Discovery earns its place when it establishes which problem needs solving and what evidence would support an investment. A list of requested screens is only one input.
Observe the current workflow
For an illustrative customer-service project, follow a request from arrival to resolution. Include spreadsheets, messages, handoffs, and exceptions. Ask the people doing the work where they wait, what information they repeat, and how they know a request is complete.
Government Digital Service guidance frames discovery around understanding users, the problem, and constraints before committing to a solution. Apply that approach by separating observed problems from stakeholder suggestions about the interface.
Test the assumption that could change the plan
If delays are caused by unclear approval ownership, a new portal may reproduce the same delay. Test a simpler change to routing or responsibility before committing to a build. If the barrier is inaccessible data, inspect a representative export or integration path early.
Agree a small set of questions the discovery must answer. Examples include whether users can identify their request status, whether source data is reliable enough to expose, and whether the organization can own the resulting service. Record uncertainty instead of filling gaps with optimistic estimates.
End with a decision and its evidence
Produce a workflow map, a prioritized problem statement, the constraints found, and a proposed next experiment or delivery slice. Explain what would cause the recommendation to change. Continuing to a prototype, buying an existing tool, improving the current process, or stopping can all be reasonable outcomes. Give the sponsor enough evidence to choose, including the assumptions behind any estimate.
