A brief that asks for a dashboard, a mobile app and an admin panel leaves a great deal unanswered. Who uses each one? Which decisions do they make? What information can they see? What happens when they make a mistake? The answers shape the work more than the number of screens does.
A clearer brief helps a business compare proposals and understand what it is buying. It also reduces the chance that two people approve the same feature name while imagining very different behaviour.
Follow one piece of work through the business.
Begin with a real task and follow it from start to finish. Perhaps a customer sends an enquiry, an employee checks availability, a manager approves a price and someone sends an invoice. Identify where information is repeated, decisions stall or records become difficult to find.
Include the people who do the work. A founder may understand the commercial goal while an administrator knows the exceptions that happen every afternoon. Both perspectives belong in the conversation. The purpose is to understand the operation well enough to make useful choices, not to collect requirements indefinitely.
Define the outcome before the feature list.
The GOV.UK Service Manual’s discovery guidance emphasises understanding the problem, users and constraints before committing to a build. The same discipline is useful in a commercial project, even when the scale and process differ from a public service.
Replace a vague request such as “automate everything” with an observable result. For example: an authorised employee can find an enquiry, assign responsibility and see its current status without searching several message threads. This does not dictate the interface, but it gives the team something concrete to design and review.
Write down the assumptions.
A scope should say what is included, what is excluded and what depends on another decision or supplier. If a payment integration requires an approved merchant account, that dependency matters. If existing records need cleaning before import, the work needs an owner. If different schools or branches have different access rules, those rules cannot be left until the final screen review.
Ask for assumptions to be written down. When an assumption changes, discuss its effect on cost, timing and priorities. That conversation is much easier when the original agreement is specific enough to compare against.
How will you know it is ready?
For each important workflow, define the normal outcome and the relevant failure or recovery states. Decide who reviews the work, what evidence is needed and how unresolved items will be recorded. A testable acceptance criterion is more useful than “make it professional”.
Mark the first-release workflow in the brief and put later ideas in a separate list. For an enquiry system, the first release might cover receiving, assigning and following up on an enquiry from beginning to end. A reporting dashboard can wait if nobody yet has a reliable way to record the work it would report on.
Read further
Original sources behind the technical guidance in this article.