How to write a clear brief for a shared note or request

A brief gives a piece of work its boundaries. Without one, the owner may create a good draft that solves the wrong problem, while the reviewer may judge it against expectations nobody stated.

A clear brief does not have to be long. It needs to explain the outcome, the audience and the constraints that affect the work. This guide applies to shared instructions, draft messages, planning notes and ordinary project requests.

Begin with the outcome

Write what the work should achieve in one sentence. “Create arrival instructions that a first-time participant can follow without calling the organizer” is clearer than “Write event content”.

The outcome helps the owner decide what belongs in the draft. It also gives the reviewer a basis for useful feedback.

Avoid describing only the format. “A one-page note” tells someone how much to write, but not what the note must accomplish.

Identify the audience and their context

State who will use the result and what they already know. A new participant needs more context than a returning volunteer.

Describe the setting in which the note will be read. A phone at the venue entrance calls for a different structure from a planning document read days in advance.

Keep audience claims factual. If you do not know the recipients' needs, state the assumption and identify how it will be checked.

Define scope and exclusions

List the information the note must cover. For arrival instructions, that might include the address, entrance, time and equipment requirements.

Then state what belongs elsewhere. The same note may not need internal budget details or the supplier negotiation history.

Exclusions help prevent the draft from expanding without a corresponding change in purpose. If a new requirement appears, record that change rather than silently treating it as part of the original brief.

The organization guide explains how separate outcomes can become separate tasks.

Record constraints that affect the result

Include real constraints: confirmed dates, required wording, source links, length limits or the need to use an existing file. Distinguish a firm constraint from a preference.

If a date is provisional, label it. If a source is incomplete, identify the missing information. The owner should not have to guess which details are reliable.

A useful brief can say:

Use the confirmed venue address. The equipment list is still awaiting review, so mark it provisional in the draft. Keep the first paragraph short enough to show the arrival action clearly on a phone.

This gives direction without inventing certainty.

Define acceptance criteria

Acceptance criteria describe what must be true for the work to be ready. They should be observable and relevant to the outcome.

For a note, criteria might include accurate dates, a named entrance, a clear first action and working reference links. “Make it professional” is too subjective by itself.

Use a short checklist:

• The intended reader can identify the next action.
• Required facts match the confirmed project information.
• Open assumptions are labeled.
• Linked material is identifiable and accessible to the audience.
• The review request names the decision needed.

The approval workflow guide explains how those criteria support a later decision on a published version.

Name the decision process

Identify who reviews the work and what kind of response is required. A factual checker and a final approver may have different responsibilities.

Set a realistic review deadline and include the time zone where it matters. Explain any dependency that affects the timing.

Draftnod's task brief and deadline fields can record the work's context. A recipient-submitted request remains pending until the owner accepts it. Submitting a request does not itself mean the work or deadline has been agreed.

Link supporting material with context

Provide source documents and examples that help the owner act. Explain what each link contributes and whether it is authoritative, illustrative or still in progress.

Do not overwhelm the brief with a folder of unexplained assets. The owner should be able to find the relevant reference without reconstructing your intentions.

W3C's accessible writing guidance recommends descriptive link text and clear headings. The links and images guide covers access checks in external services.

Use a compact brief template

Outcome: what the note should help the reader do. Audience: who will use it and what they know. Scope: the required information. Constraints: confirmed facts, limits and dependencies. Sources: named references with their purpose. Acceptance: the checks that make the result ready. Review: who responds, on which version and by when.

Keep the template proportional to the work. A simple instruction may need a few sentences; a complex handoff may need separate supporting notes.

Revisit the brief when requirements change

Feedback can reveal a missing assumption or a new need. Update the brief when the requested outcome changes, and preserve the distinction between correcting the draft and changing the scope.

The asynchronous feedback guide helps reviewers describe issues precisely. The project handoff checklist helps when the completed work transfers to another person.

Open your workspace and write the outcome and acceptance criteria before adding the first draft. A useful brief makes the next step clear for the owner and the decision clear for the reviewer.