We want a modern website can begin a conversation, but it should not begin production. Modern may mean easier publishing, stronger credibility or fixing a frustrating mobile experience. I use the brief to uncover the actual need.
Why will people visit?
Reading an article, evaluating a project and making contact require different paths. Appealing to everyone does not define those paths. I identify a few priority needs and the evidence supporting them.
What is currently going wrong?
Specific examples help: information that cannot be found, a form that fails, a page nobody can update or a confusing language switch. Turning a complaint into an observable situation makes the problem more tractable. A content problem is unlikely to be solved by changing colours alone.
Who owns the content?
Writing, images, translation and verification need named owners. Who adds the next article after launch, and who checks it? The content approval workflow is part of the product’s operating conditions, not a separate administrative detail.
A small publication may need a simple single-editor process. A multilingual publication with several contributors may need different permissions. I avoid adding complexity without a reason, while also avoiding postponing a real requirement until it becomes expensive to address.
What must be preserved?
Existing addresses, useful copy, downloadable files and images belong in an inventory. A redesign is not a reason to erase the past. Decisions about retaining and moving content should be explicit before implementation.
How will we know it is finished?
Visual appeal alone is not an acceptance criterion. Successful message delivery, correct language pairing, usable mobile navigation and a working editorial process are outcomes that can be checked.
I close the brief with exclusions and unresolved questions as well as commitments. A starting document that makes uncertainty visible gives the project a more dependable basis for completion.