How to Write a Page-Purpose Brief Before Creating Website Content

Before anyone drafts a new or substantially revised website page, complete a one-page decision record covering nine fields: intended audience, user question, page role, key message, required evidence, desired action, format, owner, and review date. First compare the proposal with existing pages, tools, transactions, and other channels. The approved outcome may be to update, combine, redirect, reject, or create. A stakeholder's proposed title or preferred format starts a discussion; it does not prove that another page belongs on the site.

Why decide the page's purpose before drafting it?

Decide first because the team needs a valid need, a distinct journey role, evidence requirements, an intended outcome, and lifecycle responsibility before treating the request as a writing assignment. Otherwise, the writer must infer those decisions from a title, a format, or scattered stakeholder comments, leaving the draft without a dependable basis for review. GOV.UK guidance similarly frames each published item around a valid user need and a record of likely users, their task, evidence, and acceptance criteria. The template below combines that principle with pre-creation planning and lifecycle governance. These exact nine fields are a practical editorial synthesis, not an official or universal standard.

What should the team check before approving another page?

Check the current site and the surrounding journey before approving another page. Search for pages, tools, transactions, support routes, and other channels that already answer the question or perform the proposed job. GOV.UK guidance advises reviewing existing content early, updating suitable pages, finding duplication and missing task information, and removing unnecessary duplication before adding more. Similar pages can blur which source is authoritative and make needed information harder to locate, while planning guidance favors one authoritative place for the same need. That does not require mechanically merging every related page; limited information at the point of need can support a transaction.

• Update an existing page when it already owns the need and role.
• Combine pages when fragments compete to provide one coherent answer.
• Redirect or retire an obsolete page when another source becomes authoritative.
• Reject the request when evidence does not establish a need or distinct page role.
• Create a page only when the need, role, evidence, action, format, owner, and review plan make a coherent proposal.

Do not brief the writer to produce a page; brief the organization to justify the page's job.

How do you define intended audience and user question?

Define the intended audience through the task, situation, or knowledge level that materially changes what the page must do, then state one central evidence-backed question or task in language that audience would recognize. GOV.UK user-need guidance calls for identifying likely users, what they are trying to do, and the evidence supporting the need. It lists analytics, call-center information, previous research, and relevant external data as possible inputs while requiring assumptions to be validated. Canada's official content style guide likewise centers organization, writing, and design on the intended audience and its main task. A broad label such as “all customers” supplies too little direction for scope, vocabulary, or evidence.

• Use research findings, support records, search behavior, journey evidence, and relevant external data in combinations appropriate to the question.
• Treat traffic as a signal to investigate, not as proof of intent by itself.
• Allow closely related subquestions when they form one coherent need.
• Do not treat a stakeholder preference, working title, or requested video as evidence that the need exists.

How do page role, key message, and required evidence work together?

These three fields define the page's unique contribution, its essential conclusion, and the proof required to publish that conclusion responsibly. Page role explains why this content belongs at a particular point in the journey and why another page, tool, transaction, or channel cannot do the job better. GOV.UK service guidance distinguishes guidance from transactional elements and recommends supplying information at the point of need. Key message states the conclusion to foreground; Canada's content guide recommends placing the most important idea, step, or information first and removing detail that does not support the main task. Required evidence covers both proof of the need and support for the eventual claims.

• A support explainer might clarify prerequisites before an administrator enters a configuration tool; the tool, not the explainer, performs the configuration.
• Evidence of need might come from research or support records, while claim evidence might require current documentation, data, demonstrations, or expert verification.
• Test the eventual title, main heading, and opening against the brief. WCAG 2.4.2 requires a page title that describes topic or purpose, helping people identify, distinguish, and judge a page's relevance; that check alone does not establish complete accessibility.

How should desired action determine the content format?

Define the desired action as what the audience should be able to decide, do, understand, compare, locate, or reach next, then choose the format that best enables that outcome. Using the action as an acceptance condition is this article's qualified synthesis of action-centered user needs and acceptance criteria; it need not be a lead, sale, or form submission. GOV.UK planning guidance connects content type and placement to audience knowledge, the task, and how users will complete it. Its service guidance also distinguishes guidance from transactions and places information at the point of need. Those principles support a decision process, not a universal taxonomy of business-site formats.

• Choose guidance when the audience needs directions or conditions explained.
• Choose a comparison when the main job is evaluating meaningful alternatives.
• Choose reference content when people need stable facts they can retrieve selectively.
• Choose a transaction step or tool when the audience must perform an interaction.
• Choose video or another format only when its strengths match the need, context, and accessibility requirements.

Who owns the page, and when should it be reviewed?

Assign one accountable person or team to own the page's accuracy and maintenance, and set the next review from actual change conditions rather than a universal cadence. Digital.gov describes content governance as extending from creation through maintenance, updating, and removal, with ownership, subject-matter verification, and approvals as distinct lifecycle responsibilities. The owner coordinates those responsibilities but does not personally replace accessibility specialists, legal or regulatory reviewers, technical implementers, data experts, approvers, or subject-matter experts. Record those contributors separately so accountability remains visible without collapsing every duty into one role.

• Base timing on known releases, policy or product changes, volatility, risk, evidence, and publishing commitments.
• Record a date and, when practical, the trigger that should cause an earlier review.
• Do not impose a quarterly, annual, or other fixed interval on every page.
• Use the checkpoint to decide whether to update, fix, consolidate, redirect, or retire the content. GOV.UK guidance notes that publishing records can expose update history and overdue scheduled reviews, but a checkpoint does not guarantee maintenance will happen.

What does a completed nine-field brief look like?

A completed brief is concise enough to review as one decision record yet specific enough to expose unsupported assumptions before drafting. Consider a hypothetical B2B support request for customers preparing to configure an integration. The example below combines evidence-backed need, pre-creation planning, acceptance conditions, ownership, and maintenance as an editorial synthesis. It makes no claim about traffic, completion, conversion, production speed, or cost savings. A real team must replace every assumption with evidence from its own products, customers, journey, governance model, and publishing environment.

• Intended audience: Customer administrators preparing to configure a supported integration.
• User question: What must I confirm before configuration?
• Page role: A prerequisite explainer positioned before the configuration tool.
• Key message: Confirm access, compatibility, and required records before starting.
• Required evidence: Current product documentation, support records showing the question, and verification by the responsible product specialist.
• Desired action: Decide whether the organization is ready, then proceed to the correct tool or support route.
• Format: Concise guidance with a prerequisite checklist.
• Owner: The product-support content team, with named product and accessibility reviewers.
• Review date: The next scheduled checkpoint, tied to a documented product-release trigger.

Approve the assignment only when stakeholders can identify evidence for the audience and question, explain why the selected decision and role are distinct, state the key message and required proof, describe a meaningful next outcome, justify the format, name an accountable owner, and commit to a review trigger and date. This approval test preserves the distinctions among evidence, task and format decisions, ownership, verification, approval, and maintenance. If a material answer remains unsupported or incoherent, return the request for research or revision. Bring in qualified accessibility, legal, regulatory, technical, data, or subject-matter professionals whenever the content requires their judgment.