Write a brief that creates momentum

Start with the decision

A useful brief does not attempt to predict every answer. It gives the team a shared definition of the problem, the audience, and the decision ahead. If the brief cannot name the decision it should support, it is usually a collection of ambitions rather than a working tool.

Try completing one sentence before writing anything else:

We need to decide what to do for which audience so that what changes.

That sentence will be imperfect. Its job is to reveal disagreement early, while changing a sentence is still cheaper than changing a finished experience.

Give the context a point of view

Background is useful only when it changes how the team should think or act. A ten-page history can obscure the two facts that actually shape the work. Edit the context until every paragraph answers at least one of these questions:

• What changed to make this work important now?
• What have we already tried or learned?
• Which organizational reality will shape the answer?
• What will happen if the team does nothing?

A good context section is selective. It gives a new team member enough orientation to ask better questions without asking them to absorb the entire organization.

Define an audience you can make decisions for

“Everyone” is not an audience, and a demographic label is rarely enough. Describe the people whose behavior or understanding matters in the moment the work should improve.

For example, “operations leaders” becomes more useful when written as “operations leaders comparing three inconsistent weekly reports before deciding where to intervene.” The second version exposes a situation, a need, and a decision. Those details can shape content, hierarchy, interaction, and measurement.

When several audiences matter, name the priority. A clear primary audience does not make everyone else irrelevant; it prevents every page and feature from trying to serve all needs equally.

Separate facts, assumptions, and open questions

Most briefs blend evidence and belief into one confident paragraph. Pull them apart.

• Facts are supported by current evidence the team can inspect.
• Assumptions are plausible beliefs that still carry risk.
• Open questions identify what the work must learn or decide.

This distinction makes research smaller and sharper. Instead of “doing discovery,” the team can test the assumptions most likely to change the direction. It also makes later decisions easier to explain: people can see which evidence moved the work and which uncertainty remains.

Name the boundaries

Constraints are not an apology. They are part of the design material. List the boundaries the team cannot wish away: timing, approvals, technical systems, content readiness, accessibility, privacy, legal review, and operational ownership.

Then distinguish a fixed boundary from a preference. “The first release must work with the existing publishing platform” is different from “we would rather not revisit the publishing workflow.” Fixed constraints shape the solution. Preferences can be challenged when they prevent a better outcome.

Describe success as observable change

Avoid success statements such as “launch a modern website” or “create a best-in-class experience.” They describe an artifact or an aspiration, not an outcome.

Ask what someone should be able to understand, decide, or do differently. Then pair that behavior with evidence the team can realistically observe. Useful measures may include task completion, qualified inquiries, content discovery, support themes, publishing speed, or confidence in a recurring internal decision.

No single number needs to carry the entire story. A small set of behavioral and qualitative signals is usually more honest than one impressive but disconnected metric.

Make deliverables serve the decision

Deliverables belong near the end of a brief. Starting with “we need a website” silently closes off questions about service, content, operations, and audience behavior.

Once the decision and outcome are clear, name the smallest artifacts that will help the team move forward. A research synthesis, prototype, content model, identity direction, or working release may all be appropriate. Each should have a reason to exist and a decision it will make possible.

Set the working rhythm

A brief should also explain how the work will stay aligned:

1. Who owns the final decision?
2. Which people provide essential expertise?
3. When will the team review evidence rather than polish?
4. What can be decided asynchronously?
5. Where will decisions and open questions be recorded?

This operating layer prevents good strategic language from dissolving into a slow approval chain.

A compact brief structure

For many digital projects, one to three pages is enough:

1. The decision: the choice or change this work must support.
2. The context: only the history and conditions that shape the answer.
3. The audience: people, situations, needs, and priority.
4. Evidence and assumptions: what is known, believed, and still open.
5. Success: observable behavior and signals.
6. Constraints: fixed boundaries and challengeable preferences.
7. Scope: the smallest useful outputs and explicit exclusions.
8. Working model: owners, collaborators, checkpoints, and next decision.

The final test is simple: can a new team member read the brief, explain what matters, and make a reasonable next decision? If not, add clarity rather than volume.