Discovery begins with the current situation

The first task is to understand why the project is being considered. For a website, that may involve outdated service information, poor mobile use or weak enquiries. For an internal application or automation, it may be repeated administration, unreliable handovers or software that no longer fits the work.

Existing websites, forms, reports, spreadsheets and process examples provide useful evidence. A polished technical brief is not necessary, but the people involved should be able to describe the problem and show how the work is currently done.

The right people need to take part

Decision-makers can explain the business priorities, but employees who perform the work often know the exceptions and practical constraints. Customer-facing projects may also benefit from examples of real questions, complaints or enquiries.

Bringing those perspectives together during discovery reduces the chance that a technically correct solution fails to fit the day-to-day reality.

Requirements are separated from possible features

Ideas are welcome, but each one needs a reason to be in the project. Discovery identifies the user or business requirement behind a proposed feature and checks whether a smaller method could satisfy it.

This is also where dependencies appear. Content, data quality, third-party software, approvals and internal availability can affect the project as much as design or development effort.

The output should support a decision

Discovery should lead to a recommendation that can be explained in business terms. Depending on the requirement, the next step may be a defined project scope, a prototype, further technical investigation or a focused improvement to what already exists.

It is also valid to conclude that a new system is not justified. Connecting current tools, changing part of a process or leaving a working website alone may be the more responsible recommendation.

Scope follows the evidence

Once the priorities and constraints are understood, the agency can define what will be delivered, what each side is responsible for and how the work will be reviewed. Assumptions and exclusions should be visible rather than buried in a proposal.

A good discovery process does not remove every unknown. It reduces the important uncertainty enough for the business to decide whether the proposed work is worth doing.