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

Before anyone drafts, complete and approve a one-page decision record with 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 resulting decision may be to update, combine, redirect, reject or create. A stakeholder's title, preferred format or urgent request is a proposed solution, not proof that another page is needed.

Why decide the page's purpose before drafting it?

Decide first because a writer needs a valid need, a distinct journey role, evidence requirements, an intended outcome and accountable ownership before the request becomes a useful production assignment. GOV.UK publishing guidance similarly starts with likely users, what they are trying to do, supporting evidence and acceptance criteria. Without those decisions, the writer must infer the audience and purpose while also trying to produce polished copy.

The nine-field brief below is a practical editorial synthesis, not an official standard. It combines principles from guidance on user needs, content planning and lifecycle governance into one record that stakeholders can assess. Use it to define the assignment and later test the draft, while retaining separate discovery, user research, accessibility, technical assessment, fact-checking and specialist approval where the subject requires them.

What should the team check before approving another page?

Check the existing site and the wider journey before approving another page. Search for pages, tools, transactions, downloadable resources and assisted channels that already address the same need or perform the proposed role. GOV.UK guidance recommends reviewing existing material early, finding suitable updates, identifying duplication and missing task information, and removing unnecessary duplication before adding content.

• Update when an existing page already owns the need and role but its content is incomplete or out of date.
• Combine when fragmented pages compete to provide one coherent answer or create conflicting versions of authority.
• Redirect or retire when an obsolete page should give way to the authoritative source.
• Reject when evidence does not establish a genuine need or a distinct page role, or another channel would perform the job better.
• Create only when the need, role, evidence, action, format, owner and review plan form a coherent proposal.

Similar pages can make the authoritative source unclear and needed information harder to locate, but consolidation should not be mechanical. A short, deliberate reminder at the point of need may help someone complete a transaction without becoming a competing source. Record why any repetition is necessary, which page remains authoritative and how the repeated information will stay aligned when facts change.

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

How do you define the intended audience and user question?

Define the audience through the task, situation or knowledge level that materially changes what the page must do, then express the central evidence-backed question in language those people would recognise. “All customers” is too broad to guide scope or explanation. “Customer administrators checking prerequisites before configuring a supported integration” gives the writer a useful context, starting point and boundary.

One central question can contain closely connected subquestions; it need not force the page into one literal sentence or one audience segment. The test is coherence: can the proposed content resolve the need for people whose circumstances require substantially the same answer? Canada's official content guide likewise centres organisation, writing and design on the intended audience and what people need for their main task.

• Use analytics to identify behaviour patterns, while recognising that traffic alone does not explain intent.
• Review call-centre or support records for recurring questions and points of confusion.
• Use prior research and relevant external data where they genuinely address the proposed need.
• Validate stakeholder assumptions instead of treating a working title, requested video or internal preference as evidence.

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

These three fields define the page's unique contribution, the conclusion it must communicate and the proof required to support it. State the page role as a job within the journey, including why an existing page, transaction, tool or other channel cannot perform that job better. Then write the key message as the essential conclusion the intended audience should retain.

Put the task-relevant substance of that message before supporting detail. Canada's content guidance recommends leading with the most important idea, step or information and leaving out material that does not help the intended audience complete its main task. Required evidence should cover two different questions: what demonstrates that the content need exists, and what sources or verification will substantiate claims made on the page?

Consider a support explainer for administrators preparing to configure an integration. Its role might be to clarify prerequisites before the configuration tool; the tool, not the explainer, performs the configuration. The evidence could include current product documentation, recurring support records and verification by the responsible product specialist. This separation reflects guidance that informational and transactional elements perform different jobs and should appear where people need them.

Once published, test the title, main heading and opening against the brief's key message. WCAG 2.4.2 requires a page title that describes topic or purpose, and W3C notes that descriptive titles help people identify pages, judge their relevance and distinguish them from others. That check supports clarity and orientation, but it is not evidence that the whole page is accessible.

How should the desired action determine the content format?

Define the desired action as what the audience should be able to decide, do, locate, compare, understand or reach next, then choose the format that best enables that outcome. Treating the action as an acceptance condition helps reviewers assess whether the content performs its intended job. It does not turn every page into a lead-generation device or require a form submission.

• Use guidance when people need instructions, preparation or context for a task.
• Use a comparison when the audience must evaluate meaningful differences before deciding.
• Use a reference when people need stable facts they can revisit quickly.
• Use an explainer when the central job is building sufficient understanding for a later step.
• Use a transaction step or tool when people must enter information, receive routing or complete an interaction.
• Use video only when demonstration, motion or another justified need makes it more suitable than text or imagery.

GOV.UK planning guidance connects content type and placement with audience knowledge, the user task and how the task will be completed. Its service guidance also distinguishes guidance from transactions and favours information at the point of need. Those sources establish a decision principle, not a universal catalogue for business websites. If a tool change, transaction improvement or non-web channel works better, record that decision instead of forcing a page into production.

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

Assign one accountable person or team to maintain the page's accuracy, then set the next review from the content's actual change conditions. Ownership is not the same as doing every specialist task. Digital.gov describes governance across creation, maintenance, updating and removal, with ownership, subject-matter verification and approvals represented as distinct parts of the lifecycle.

Record contributors, subject-matter reviewers, approvers, accessibility specialists, technical implementers and legal or regulatory reviewers separately when they are required. The owner coordinates the work and ensures decisions are followed through; the owner does not replace specialist judgement. This distinction also makes an escalation path visible when evidence is disputed, a release changes the product or an approval expires.

Set a review date alongside a meaningful trigger, such as a product release, policy change, evidence update or known contractual milestone. The appropriate timing depends on volatility, risk, evidence and publishing commitments, so one quarterly or annual rule will not suit every page. GOV.UK guidance notes that publishing records can expose overdue reviews and support later decisions to update, fix or retire outdated content.

• Record both the planned date and any event that should prompt an earlier review.
• Confirm who monitors the trigger and who can authorise a change.
• At the checkpoint, choose deliberately among updating, fixing, consolidating, redirecting or retiring.
• Treat the date as a commitment to reassess, not a guarantee that maintenance will happen.

What does a completed nine-field brief look like?

A completed brief should let stakeholders see the entire page decision on one concise record before assigning a draft. The following hypothetical example concerns a B2B support page; it makes no claim about traffic, completion, conversion, cost savings or any real product. A real team would replace every assumption with evidence from its own users, systems and operating context.

• Intended audience: customer administrators preparing to configure a supported integration.
• User question: What must I confirm before configuration?
• Page role: a prerequisite explainer immediately 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 organisation 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, linked to a documented product-release trigger.

Approve the assignment only if stakeholders can show evidence for the audience and question, explain why the decision and page role are distinct, state the key message and its required proof, describe a meaningful next outcome, justify the format, name an accountable owner, and commit to a review date and trigger. If any material answer is unsupported or contradictory, return the request for research or revision before drafting begins.

Once approved, the brief becomes a focused production contract and a review reference, not a promise of success. Bring in qualified accessibility, legal, regulatory, technical, data or subject-matter professionals whenever the proposed content contains claims or implementation decisions requiring their judgement. The accountable content owner coordinates those contributions and approvals but does not absorb or replace the specialists' responsibilities.