A good brief needs no technical language. Learn how to describe the problem, share evidence and define success so your website project starts on solid ground.
Article:
Many website projects go astray before a single line of code is written. The cause is rarely a lack of talent on the developer's side. It is usually a brief that describes a solution the client has imagined, rather than the problem the client needs solved. Fortunately, a useful brief requires no technical vocabulary at all.
Describe the problem, not the solution
"We need a new homepage with a video banner" is an instruction. "Visitors leave without finding our pricing" is a problem. The second statement invites an informed response, while the first quietly rules out better ideas. State what is not working, whom it affects and how you know.
Share your evidence
Bring whatever data you have, however modest: visitor numbers, the pages people leave from, the questions customers ask most often, competitors you admire and the reasons why. Even a few screenshots of sites you find frustrating can be revealing. Evidence turns a preference into a requirement.
Be candid about constraints
Budgets, deadlines, existing systems and internal approvals all shape what is possible. Disclosing them early is not a weakness in negotiation; it prevents a proposal that cannot be delivered. Mention any tools the site must connect to, such as a booking system, a customer database or a payment provider, because integrations are where hidden effort tends to accumulate.
Firms that offer end-to-end website development, from content management to technical search will usually welcome a brief framed in this way, as it lets them propose a complete approach rather than a narrow one.
Agree what finished means
Before work begins, write down how success will be recognised. It might be a faster page, a higher enquiry rate or an editor who can publish without assistance. Without a shared definition, a project can be technically complete and still leave the client dissatisfied.
A brief is not a contract or a specification. It is the start of a conversation, and the clearer it is about the problem, the better the conversation tends to be.
Sign in to leave a comment.