Creating and redesigning websites

Website brief: questions that prevent a generic project

Build a website brief around decisions about the audience, offer, evidence, content, operations, access, and approval criteria.

By Anderson, who leads Natander. Editorial reading, with no promise of results

The brief should record decisions

A useful brief is not a form for choosing colors, visual references, and a page count. It records decisions that guide content, architecture, interface, technology and approval. Start by asking why the website is needed now, what change the company expects it to support, and which audiences need answers. If the objective cannot be explained, the project tends to fill space with generic elements. The document must translate intention into observable criteria.

Also document constraints: feasible deadlines, available people, existing assets, integrations, industry rules, access, and dependencies. Restrictions do not reduce the quality of the project; they make the scope real. A clear document shows what will be decided in the project and what needs information or approval before starting. This transparency reduces rework and provides a basis for setting priorities without improvisation. Briefing makes the operational agreement visible to everyone.

  1. Write objective, moment and decision that the site should support.
  2. Identify real audiences, accountable owners, and constraints.
  3. List necessary dependencies and approvals.
  4. Distinguish confirmed requirements from working hypotheses.

Describe the audience, offer, and fit

Ask who is looking for the company, in what situation, and with which questions and decision criteria. Then describe each service in terms of scope, process, requirements, and limits. A phrase such as “we serve everyone” does not help anyone design a page or contact path. The more concrete the situation, the easier it is to decide which information should be highlighted. The brief should capture language customers actually use, not just internal terminology.

The brief should also record who is outside the target audience and which requests the company does not accept. This clarity protects the service and prevents the site from promising unrestricted availability. If different services involve different decisions, give them dedicated pages, messages, and calls to action. The goal is not to artificially restrict communication, but to align expectation and capacity. Well-written limits help the team respond consistently after release. They also inform the form's architecture and filters.

  1. Describe search situations and real doubts.
  2. Detail scope, process, service requirements and limits.
  3. Record requests that fall outside the target audience or available capacity.
  4. Link each offer to a page and a next step.

Request verifiable evidence and usable content

A project should not fabricate authority because the brief lacks evidence. List what evidence there is, who authorizes its use, what they demonstrate and in what context they may appear. Credentials, certifications, processes, samples and testimonials fulfill different functions. If there is no public proof, the site can still explain method, responsibility and limits without inventing numbers, customers or results. The absence of a case does not prevent an honest narrative about work.

Define who will provide the copy, images, documents, FAQs, and legal information, along with the review deadline. Content needs to have source, responsibility and approval status. It is also worth indicating what cannot be stated in the sector. This preparation prevents the layout from being completed with provisional text blocks that then do not represent the company. An approved editorial baseline guides both the launch and future updates. The record protects the brand's voice without standardizing everything.

  1. Inventory the evidence, sources, authorization, and context.
  2. Name those responsible for texts, images and documents.
  3. Mark provisional content and revision date.
  4. List statements and materials that should not be used.

Define the scope, access, and approval process

The brief should state which pages, integrations, forms, languages, environments, and deliverables are in scope. Include the domain, hosting, analytics, ad accounts, image library, and consent tools, always defining company ownership and access. Without this inventory, the project can end visually ready and operationally dependent on an unknown person or service. The list of assets also prevents delays in publication and public validation on each delivery.

Define how revisions, acceptance, testing, and launch will work. An approval should state what was reviewed and who has authority to sign off. Register quality criteria: content, responsiveness, accessibility, routes, safety, measurement and observed performance. Briefing becomes a shared reference to resolve disagreements without turning late opinion into infinite scope. Each review round should have a defined question and one owner responsible for the answer. This prevents a change of opinion from being confused with a defect.

  1. Set pages, integrations, environments and deliverables.
  2. Confirm company ownership and the access required.
  3. Establish owners, review rounds, and acceptance criteria.
  4. Include QA of content, interaction, accessibility and measurement.

Reference sources

Want to identify the bottleneck before investing?

Natander connects your website, media, content, and data in a focused diagnostic, with documented priorities and clear limits.

Request a diagnosis
Menu
Request a diagnosis