Why a brief is a starting point, not a full diagnosis
A good brief is the most useful document a project starts with. It is also written from one vantage point, at one moment, which is why we read it as a set of well-informed hypotheses rather than a finished diagnosis.
What is a brief, and what isn’t it?
A brief describes what an organization believes it needs, written from where it stands when the project begins. It is the best starting point a project has, but it rarely contains everything needed to understand the situation, so we treat it as a set of hypotheses to explore before we design a response.
That is not a criticism of briefs or of the people who write them. A brief that tried to anticipate every question would take months to write and still miss something. Its job is to open the conversation with clarity: what you want to achieve, what prompted the project, what you already know. Our job is to take it seriously enough to look closely at it.
What a brief does well
Most briefs we receive are thoughtful. They carry knowledge we could not get anywhere else:
- the business objective and why it matters now
- the history: what has been tried, what was decided and why
- constraints that are real and non-negotiable, such as dates, systems, regulation or brand commitments
- the people involved and who will make decisions
This is the foundation. When we ask questions about a brief, we are building on it, not replacing it.
What can a brief not contain?
Some things are hard to see from inside an organization, however well it knows itself. Others only become visible once someone starts working on the problem. A brief usually cannot fully capture:
- How work actually happens. Processes on paper and processes in practice drift apart over time, often for good reasons that nobody wrote down.
- The people who were not in the room. Front-line staff, editors, customers and partners experience the problem differently from those who commissioned the project.
- Tacit knowledge. The workarounds, habits and shortcuts that keep things running are rarely described, because to the people using them they are simply how things are done.
- The difference between a need and a solution. “We need a new website” or “we need a dashboard” is often a sensible conclusion. It is still a conclusion, and it helps to understand the need that led to it.
How do we read a brief?
In Define & Explore, we read a brief with a set of questions that help us understand the context around it. Not every project needs all of them, and some are answered in a single conversation:
- What prompted this project now, and what would happen if it did not go ahead?
- Who will use the result, and in what situation?
- What would success look like a few months after launch, in plain words?
- What has already been tried, and what did you learn from it?
- What must not change?
- Who owns which decisions, and who else will be affected?
Then, where possible, we go and see. That might mean stakeholder interviews, a review of the existing experience, a look at analytics, or time spent observing the work where it happens. The scale depends on the project. A focused engagement might need a few well-chosen conversations; a complex, multidisciplinary initiative might justify a longer discovery phase.
The brief tells us where to look. Looking is still our job.
Efabrika
What happens when the picture differs from the brief?
Sometimes Define & Explore confirms the brief almost exactly. That is a useful result: you can move into Design & Develop with more confidence, and with evidence to share inside your organization.
Sometimes it shows that the need is slightly different from how it was first described, or that a different response would serve it better. When that happens, we explain what we found, how we found it, and what the options are. We are clear about what each option would mean for scope and timing, and we respect that you know your organization and make the decision. A brief that changes for good reasons is a sign the process is working.
What we avoid is quietly delivering exactly what was asked for while suspecting it will not serve the need. Honest scope means saying what we will deliver, what we will not, and where we think the question deserves another look.
Keeping the brief alive
The most useful briefs do not stay frozen. We often turn the original brief and what we learned during Define & Explore into a shared, short statement of the problem, the people it affects and what success means. That document guides decisions during Design & Develop, and it becomes the reference point when we Optimize after launch: did the work do what we set out to do, and has the context moved on since?
Because the loop returns to Define & Explore, the brief is not only a starting point for one project. It is the first version of an understanding that keeps getting better.
If you have a brief, or just the outline of one, we are happy to read it with you. You can learn more about how we work on our Approach page, or get in touch.