How to Turn a Vague Project Request into an Executable Brief

“We need a website like that brand, but more modern and faster.” It is a useful opening sentence, not an executable brief. If a team estimates price and delivery from that sentence alone, the project will eventually hear: “That is not what we meant.”

A good brief does not restrict creativity. It brings the expensive ambiguities forward, while they are still cheap to discuss. Think of it as a reviewable agreement: what problem are we solving, for whom, under which constraints, and how will we know the first release worked?

Start with the problem, not the deliverable

“We need an app” is not yet a problem statement. What does the user do today with calls, spreadsheets or messages, and where does that process fail? A service company may need faster request handling. A store may need to reduce product-search friction. An internal team may be copying the same data between tools.

Try one measurable sentence: “We want new requests to receive a useful response within a few hours instead of two days.” It gives the team a target and gives the project a way to judge trade-offs. If no behaviour or business outcome is expected to change, the project may not be defined yet.

Five decisions to make before estimating

1. Primary user: Who uses the experience and how confident are they with technology?
2. Critical journey: What action proves success—submitting a request, paying, booking or receiving a report?
3. Version-one boundary: What is essential for launch, and what is explicitly postponed?
4. Constraints: Which systems, APIs, security rules, budget and approval owners already exist?
5. Acceptance criteria: What can be tested instead of described as “modern” or “easy”?

A small change that saved a project

An education company initially asked for a page that “showed all courses.” Discovery revealed that the business did not sell online; advisers needed qualified enquiries and visitors needed to compare options quickly. The first release therefore focused on filters, comparison, a short enquiry form and a clean handoff to sales. A smaller scope matched the real business better than a large shopping flow.

That is the practical value of a brief. It prevents a team from turning an attractive assumption into working software.

Keep the brief alive

Projects change. Add a small section for open decisions, risks and approval owners. Whenever scope changes, state the effect on time, cost and the first release. This does not eliminate difficult conversations; it makes them specific.

It also protects content quality. Google’s official guidance recommends creating helpful, reliable, people-first content rather than pages made mainly to attract search traffic. Google’s people-first content guidance is a useful check for any article or service page: would a visitor have enough clarity to take the next step?

The one-minute test

If the team cannot explain the audience, problem, first-release scope and success measure in one minute, design is probably starting too early. At Digi Orbit, we turn the initial request into a discovery conversation, a user journey and a staged estimate. You do not need a technical specification to begin; you need an honest description of the problem and the constraints around it.