VanThunder Journal
Planning 9 min read

The website brief that prepares real decisions

An editorial briefing structure for goals, audiences, content, functions, ownership, budget and measurement.

Marvin Schubert Author · strategy, development and SEO
Read the article ↓ 4 primary sources
Modular 3D planning system with ordered cards, layers and a clear progress path
AI-assisted editorial illustration, art-directed and reviewed by VanThunder · stored and served locally

Key takeaways

  • A good brief does not answer everything; it exposes assumptions, decisions and open questions.
  • Commercial goals and user jobs come before style words or technical preferences.
  • Content, approval and measurement need named owners.

01

1. Goal and current state

Begin with the problem, not the desired interface. Explain why the project is necessary now, where the existing site underperforms and what change the business expects. “Look more modern” is a direction; “generate more qualified enquiries for service X” is a testable objective.

Add a baseline using available evidence: important entry pages, monthly enquiries, known search terms, recurring support questions or sales feedback. Google recommends content created primarily to help people, with a clear intended audience. The brief should make that audience and context tangible.

Sources: Google Search Central

02

2. Audiences, jobs and content

Do not stop at demographic personas. Describe situations: what does the visitor need to decide, what are they worried about and what evidence will help? Those questions generate page types and content. A service page needs different proof from an article; a careers page has different tasks from support.

Create a content matrix with purpose, core message, evidence, next action, existing material and owner for every page. Missing photography and approvals become visible early, preventing development from finishing while crucial copy remains placeholder text.

  • Primary audience and decision context
  • Questions, objections and desired next action
  • Proof: case work, data, process, credentials or people
  • Content source, owner and approval date

Sources: Google Search Central,Google Search Central

03

3. Functions, systems and boundaries

Describe functions as workflows. Instead of “CRM integration”, specify which form data enters which system, who is notified and what happens on failure. Instead of “multilingual”, define languages, URL structure, translation ownership and publishing workflow.

Boundaries matter equally. Which browsers are supported? What can the team edit? Which data must not be processed? Which dependencies involve IT, privacy or external partners? A good brief does not suppress creativity; it creates a safe space for relevant design.

Sources: Google Search Central

04

4. Budget, timing and success

State a realistic budget corridor. Without one, a supplier may optimize for an entirely different solution class. Separate target date, hard dependencies and internal approval capacity. Timelines are often delayed by missing content and decisions rather than engineering.

Close with three to five success criteria. They may be quantitative—qualified leads, organic entries, load times—or qualitative, such as a clearer sales narrative or easier editing. Name the data source, baseline and first review date. The brief then becomes the beginning of a learning system.

Sources: web.dev

Conclusion

The best brief is not a long questionnaire. It is a decision document. When goals, users, content, systems, boundaries and measurement are clear, a team can design faster and say no for good reasons.

Editorial responsibility

Written by
Marvin Schubert
Professionally reviewed by
Marvin Schubert
Published
Last substantive update
Sources checked through
29 July 2026
Read the full editorial standards →

AI disclosure

Researched and structured with AI assistance; professionally reviewed and editorially revised by Marvin Schubert, then verified against the linked primary sources.

Change history

· Initial publication; arguments, recommendations and sources reviewed before release.

Apply the article to a real project.

We turn the principles into a clear scope, design system and measurable implementation.

Discuss your project