Write what will exist, who will use it, what limits the work, who decides, and how the team will know it is complete.
“Can you improve this?” may begin a useful conversation, but it is not yet a reliable instruction. One person may imagine a spelling pass while another imagines a new structure, visual design, and approval cycle. The gap appears later as rework.
A brief does not need to be long. It needs to make the main assumptions visible while they are still inexpensive to change.
Name the thing that will exist
Start with a concrete deliverable: a revised two-page guide, a set of three product screenshots, or a decision about which supplier to use. Avoid describing only the activity, such as “work on onboarding.” Activities can continue without producing a finish line.
Include the current version or source material and say what may be changed. If a draft contains legally approved language or accessibility requirements, identify those constraints before editing begins.
Describe the reader or user
“For everyone” rarely helps. Name the situation: a new customer setting up an account, a manager comparing two options, or a colleague taking over next week. The audience description should influence the language, detail, and format.
Do not invent demographic details that the work does not need. Use real access needs and context when they are known, and mark assumptions that still require confirmation.
Separate requirements from preferences
Create two lists. Requirements might include a deadline, supported language, legal wording, file format, or device size. Preferences might include tone, visual references, or an optional example.
This distinction prevents an attractive preference from quietly displacing a necessary condition. It also gives the person doing the work room to make decisions where the requester has no strong view.
Record who decides
Name the person or role that can accept the result. Feedback from many people can be valuable, but someone needs to resolve conflicting comments. Write when the decision is needed and what happens if an input arrives late.
A compact brief can use six lines:
| Field | Question |
|---|---|
| Outcome | What will exist? |
| Audience | Who uses it, and in what situation? |
| Inputs | What material is current and trustworthy? |
| Constraints | What must be preserved or supported? |
| Decision owner | Who accepts the result? |
| Done | What evidence shows completion? |
Confirm by reflecting it back
Send a short summary in your own words: “I will revise the setup guide for first-time customers, preserve the approved policy section, and deliver a reviewable document Thursday.” Ask about the one uncertainty that would most change the work.
Reflection is especially useful when a request arrived through several people. It exposes drift without requiring a meeting about every small task.
Keep the brief current
When scope changes, update the brief and note the decision rather than leaving the new expectation inside a private message. A brief is a working agreement, not a historical transcript.
The goal is not perfect certainty. It is enough shared context for someone to begin useful work and enough evidence to recognize when that work is complete.
Questions about this article? Contact the publication.
Editorial policy