AEO Content Briefs: Specify the Answer Before the Article

Write the page promise before the outline

A brief should begin with the result the reader needs. “Write about data exports” gives a writer a subject but no decision. “Help an account administrator export the correct invoice records before closing an account” specifies the audience, task and important context. That promise becomes a practical editing test. If a proposed section does not help the administrator complete or understand that task, it needs a clear reason to occupy space in the article.

Include the starting point. Does the reader know the terminology? Have they already chosen a product? Do they have administrator access? A guide can be accurate yet unusable because it assumes a permission or concept the reader lacks. State what the article may assume and what it must explain. GOV.UK’s user-needs guidance provides a useful task-centred foundation. The brief turns that broad principle into the particular reader situation this page will serve.

Add a provisional answer, clearly marking any uncertainty that still needs research. This is an internal working statement, not a promise to publish an unverified claim. For an illustrative export guide, it might say that administrators can download records but must confirm attachment handling and retention behaviour. Those unknowns are more valuable than a confident invented summary. They tell the writer which facts determine the advice and prevent a polished outline from concealing an unresolved premise.

Draw boundaries that prevent duplicate articles

Name the primary question and the adjacent questions owned elsewhere. A page about choosing export formats should not quietly become a second guide to requesting account access. Link the relevant destination in the brief and describe the hand-off. The writer can give enough context for the current task, then direct readers to the detailed explanation. This is more useful than an arbitrary instruction to “avoid overlap”, because it identifies exactly which explanation belongs on another page.

Use the existing library to make those decisions. The topical map can show candidate relationships, but inspect the actual content before assuming a title proves coverage. If a nearby article already answers the proposed central question, revise the commission or improve that article. A brief is the cheapest place to stop duplication. Once two similar drafts exist, teams often preserve both because work has already been spent, even when readers would benefit from one stronger destination.

Specify a primary query as a useful label for the intent, not as a phrase quota. Include natural variants only when they reveal a meaningful difference in audience language or conditions. A long list of near-identical keywords can encourage awkward repetition without improving the answer. Question research should already have grouped equivalent wording. The brief needs the resulting decision and representative language, rather than every raw phrase collected during discovery.

Describe the evidence the claims require

Build an evidence list around claims, not a general collection of links. For each changeable fact, note the preferred source and the exact question it must settle. A pricing page may establish a plan name while failing to explain a permission rule. A help article may describe behaviour but apply only to an older version. Ask the writer to verify the match between source and claim, including edition, date and conditions. This makes research purposeful and easier to review.

Separate primary facts from original explanation. Official documentation can establish what a feature supports. The writer’s contribution may be an example showing which workflow fits that capability. Google’s review guidance emphasises useful distinctions and evidence in evaluations. A brief for a comparison should therefore ask for a consistent criterion and an explained trade-off, rather than a table of unexplained ticks or a winner chosen before the research begins.

State what cannot be claimed. If no hands-on test is planned, the article must not describe desk research as testing. If a numerical example is invented to explain a calculation, label it illustrative. If a source provides a capability but no measured outcome, do not infer a conversion improvement. These boundaries protect the meaning of the final article. They are more precise than a generic demand to “be authoritative”, which can accidentally reward confident wording over supportable information.

Give the writer a difficult case to solve

A useful brief includes an example that exercises the article’s hardest condition. For a permissions guide, choose two roles with different access. For a migration guide, include a record that cannot be transferred automatically. For a comparison, choose a reader whose needs make the obvious popular option unsuitable. The example exposes whether the planned explanation can survive contact with a real decision. It also gives the writer material that is more distinctive than another summary of familiar definitions.

Provide an outline only where the dependencies are already clear. A procedure may need prerequisites before steps; a conceptual explanation may need a simple model before exceptions. Avoid forcing every page into the same sequence of benefits, challenges and tips. Ask for answer-first content when a direct opening will help, then let later sections follow the reader’s actual questions. A brief should constrain purpose and accuracy while preserving room for a better explanation to emerge during research.

Specify supporting formats by function. A table should compare the same criteria across options. A diagram should clarify a relationship or branch that prose alone makes difficult to follow. A screenshot should show an interface detail the reader must recognise. Requesting “one visual” without a purpose invites decoration. Describe what the reader should learn from the asset, and identify the exact data or labels it needs, so production does not invent unsupported detail to fill space.

Make acceptance criteria observable

Replace subjective requirements such as “comprehensive” with checks tied to the task. The export guide must identify the required role, explain format choices, show where attachments go and describe how to recognise a complete export. A reviewer can assess those points directly. Length can be a planning estimate, but it cannot prove completion. A long article that omits attachment handling still fails the brief, while an efficient explanation should not be padded simply to look substantial.

Assign responsibility for open questions before drafting starts. A product specialist may verify behaviour; an editor may check source support; a developer may confirm a code example. Set a clear decision point for unresolved claims so the writer does not quietly guess under deadline pressure. The content review checklist should follow the same acceptance criteria. When drafting and review use different standards, feedback tends to become an argument about preferences rather than whether the page fulfils its purpose.

Finish the brief with the page’s intended next step and maintenance triggers. A reader might continue to a configuration guide, compare alternatives or complete an operation elsewhere. Link that destination contextually instead of adding a generic sales ending. Identify which product or policy changes would require revision. Content governance supplies the broader ownership system, while the brief records the specific obligations of this page. The finished document should let a writer begin with confidence about the task and honesty about the evidence.

Sources and further reading

• GOV.UK identifying user needsUser needs should be based on actual user tasks.
• Google high-quality review guidanceReviews should explain relevant differences and support evaluation with evidence.