I have a fondness for the slightly uncomfortable line in a brief.
The one that says the team hasn't settled whether the offer includes a visit. Or that the intended audience needs checking. Or that the service name means different things to different colleagues.
It is less elegant than the rest of the document. It is often more useful.
A polished brief can accidentally make uncertainty look like agreement. Everyone reads a confident sentence and assumes someone else has confirmed it. The creative team builds around it. The approval meeting eventually discovers that the foundation was still wet.
We then become very busy repairing the room.
An honest question saves a round
In a fictional planning exercise, I wrote two versions of the same brief. One described a “complete assessment” confidently. The other asked what the assessment included and named the colleague who would confirm it before the headline was approved.
The second version was less satisfying to send. It was much more satisfying to use.
The writer could see the open point. The designer knew which part of the page might change. The service team had a specific question to answer. Nobody needed to guess whether the phrase had already been signed off.
That didn't mean the whole project had to stop. Work on the settled material could continue. The uncertainty had a boundary.
I would like more briefs to distinguish between decisions, assumptions and questions. Not with an elaborate colouring system that itself requires a meeting. A few clear labels and an owner can be enough.
“Assuming the visit is included; needs confirmation before publication” is plain and useful. “Delivering an integrated customer experience” may sound more impressive, but it leaves everybody doing detective work.
Keep the question answerable
An open point should state what somebody needs to find out and what will depend on the answer.
“Need more detail” is difficult to act on. “Does the introductory session include written recommendations?” is a question a colleague can resolve.
The brief can also say when the answer is needed. If it will determine the central promise, that decision belongs early. If it affects one supporting example, the rest of the work may have more room to proceed.
This sounds obvious until the project is moving quickly. Then a vague note can travel through three documents without anybody remembering who was supposed to deal with it.
I've done it. A small question became a stubborn visitor at every review. By the fourth appearance, we all knew it was there and nobody particularly wanted to introduce it again.
Naming an owner would have been a damn sight kinder to everyone.
Let the brief change visibly
Once a question is resolved, record the answer where people are working. Tell the colleagues whose material depends on it. A new fact sitting in a private email is not yet a useful project decision.
Keep enough history to explain the change without making the brief a transcript of every conversation. The production team needs the current answer and the relevant reason.
I don't want a brief that celebrates uncertainty for its own sake. The point is to help the team settle it.
But I'd rather see one candid line about an unanswered question than a beautifully written paragraph pretending the answer exists.
A brief is allowed to show where the work still needs thinking. That is part of what makes it a good brief.
A thought worth keeping?
