Seven questions to answer before anyone quotes you

Most projects that go over budget, over time, or over everyone's patience share an origin: a brief too vague to define what success looked like.

"I need a professional website" is not a brief. "We need to modernise our systems" is not a brief. Both are aspirations, and an aspiration has no success criteria — so there is no way for either side to know whether what gets built is working. Something gets delivered. It gets accepted. Nobody can say whether it is doing anything.

A clear brief does three things for you. It makes the work cheaper, because what is being built is what you need rather than what is discovered halfway through. It makes it faster, because the decisions that would otherwise stall the middle of the project have already been made. And it makes competing proposals comparable, because they are all responding to the same specification.

Writing one requires no technical knowledge. It requires honest answers to seven questions.

1 · What does it need to do?

Not what it needs to look like. Not which pages or modules or screens it needs. What does it need to do — functionally, operationally — that is not being done now?

"We need a new system" is not an answer. "We need our clients to book without phoning, see their history with us, and settle invoices without three emails" is an answer. "We need to know, on any given day, which of our seven entities is carrying the shortfall" is an answer.

The functional requirement is the foundation. Everything else is built to serve it, and once it is clear, scope decisions become easy to make and easy to defend — which matters more than it sounds, because most scope arguments are really arguments about an undeclared requirement.

2 · Who is it actually for?

Not everyone. That is never the right answer, and something designed for everyone is optimised for nobody.

The primary audience is the specific person whose behaviour has to change for this to have been worth doing. The customer you most want more of. The back-office team who will use it forty times a day. The executive who needs one number on a Monday. Their comfort with technology, the device they will be holding, and what they are trying to accomplish when they arrive.

You do not need a formal persona document. You need to be able to describe that person in three sentences.

3 · What is the one action you want?

Every effective system has a primary action it exists to produce. Book the consultation. Submit the claim. Approve the invoice. Complete the application.

When this is undefined, the result is an information brochure with equal weight on every page and no path to the outcome. When it is defined, every subsequent decision can be tested against it: does this help the primary action, or compete with it?

If you find yourself listing three or four equally important actions, rank them anyway. First, second, third. The first is the one the thing is built around; the others must not compete with it visually or structurally. Refusing to rank is a decision too — it just gets made later, by accident, by whoever is building.

4 · What already exists that is worth keeping?

An existing domain. Brand assets. Photography. Copy that works. A client database that has to come across. Knowing what exists stops it being unnecessarily rebuilt or accidentally discarded, and both of those are expensive in ways that only become visible afterwards.

This applies equally to what has not worked. A brief that includes "here is what the last attempt did, and here is why I think it failed" is genuinely useful. It is also the single most informative paragraph most briefs could contain and almost never do.

5 · What have you seen that you admire?

You do not need design taste to answer this. You need to have opened a few things in your sector, noticed that some feel right and some feel wrong, and be able to point at examples of both.

Three references with short notes — this one is laid out well, this one feels too corporate for us, this one is what I wish our reporting looked like — give more actionable direction than a paragraph describing the abstract.

If you genuinely have no references, say so. That is also information: it means whoever is doing the work has more latitude, which changes how the project should be scoped.

6 · What is the problem costing you now?

This is the question most briefs get backwards, and it is the one worth the most.

The conventional advice is to state a budget range. I understand why — a range stops both sides wasting time on a proposal aimed at the wrong scale. But a budget stated in the abstract is a guess about what something ought to cost, made by the person least equipped to make it, and it quietly caps the work at whatever was guessed.

The better question is what the problem is costing you today. Hours a week spent reconciling two systems that should be one. Enquiries that go unanswered overnight. A month-end that takes four days. Work that has to be redone because the first version was built on stale information. Put a number on the ones you can and be honest about the ones you cannot.

That figure does two things a budget cannot. It tells whoever is scoping the work where the value actually sits, so the proposal attacks the expensive problem rather than the visible one. And it gives you the only sound basis for deciding what to spend — not what a thing like this usually costs, but what this particular problem is worth solving.

If the cost of the problem is genuinely small, that is the most valuable answer of the seven, because it means the honest recommendation is to do less than you were about to.

7 · What is the timeline, and is it real?

Some deadlines are hard — a board date, a regulatory commencement, a contract requirement, a trade show. Others are soft: as soon as possible, before the end of the year.

The distinction matters because hard deadlines change resourcing and sequencing, and because the difference between them is where mismanaged expectations come from. If it is hard, say so and say why it is hard. If you are flexible, say that too. Four months and four weeks are different projects, and usually the longer one produces better work for the same money.

What you do not need to have figured out

A brief does not need a finished design, a technical specification, a list of every screen, a sitemap, or a technology preference.

You do not need to know which framework or which database. You do not need wireframes or a mood board. Answers to the seven questions above are enough for anyone competent to propose an appropriate approach — and if they are not enough, that tells you something useful about who you are talking to.

The brief is about the business problem and the people it affects. The technical solution is not yours to specify, and a proposal that asks you to specify it is asking you to carry a risk you are not being paid to carry.