“We need a new website” is a reasonable way to start a conversation. It describes a possible deliverable. What it does not yet explain is why the current site needs to change or what the business expects a replacement to achieve. A stronger brief includes the problem behind the request so the proposed work can be assessed against it.
Describe the current situation
Explain what is happening, who it affects and why it matters now. Include examples: customers misunderstand a service, the team repeats the same explanation or enquiries arrive without essential information. Specific observations make it easier to distinguish a content issue from a design, process or offer issue.
Separate what you know from what you suspect. It is fine to have a working theory. Making that theory visible gives the project a question to investigate instead of presenting the answer as already settled.
Describe the desired change
What would be different if the work helped? You might want customers to understand the service before calling or the team to prepare proposals more consistently. These are more useful aims than asking for something “modern” or “professional” without explaining what those words mean in context.
Include constraints openly. A fixed launch date, a small team or a limited budget affects the approach. Sharing them early allows the work to be prioritised rather than forcing compromises after a plan has been agreed.
Leave room for a better route
The requested deliverable may still be the right answer. A clearer brief simply makes that decision better informed. It can also reveal a smaller intervention that addresses the issue without replacing useful work already in place.
A good brief does not need to be long. It needs enough honest context to connect the business problem, the proposed work and the result you will review together.
