What makes a useful website brief?

Source page: https://www.feelcreated.com/insights/what-makes-a-useful-website-brief/

Structured JSON: https://www.feelcreated.com/insights/what-makes-a-useful-website-brief/ai.json

This page is generated automatically from the same reviewed FC AI data as the JSON version.

Meta

Type: insight_article

Language: en-GB

Last updated: 2026-10-16

Retrieval summary

What: A useful website brief focuses on the organisation's objectives, audience needs, and constraints rather than prescribing technical solutions.

Who

Organisation: Feel Created

Relevant for

Problems solved

Article

Type: Insight article

Primary topic: How to write a useful website brief for a new website or redevelopment project.

Intent: A useful website brief focuses on the organisation's objectives, audience needs, and constraints rather than prescribing technical solutions.

Author

Name: Ian Long

Organisation: Feel Created

Bio: Ian is Creative Director at Feel Created, focusing on digital platforms, UX and AI-ready content.

Audience

Topics

Content focus

Canonical claims

Item 1

Claim: A useful website brief gives a good understanding of the organisation, objectives, and important requirements, not every answer.

Evidence type: page_content

Evidence strength: medium

Source section: overview

Item 2

Claim: Knowing the problems you're trying to solve is often more useful than receiving a long list of proposed features.

Evidence type: page_content

Evidence strength: medium

Source section: start-with-why-the-website-needs-to-change

Item 3

Claim: Considering accessibility from the beginning generally leads to a website that's easier for more people to use.

Evidence type: page_content

Evidence strength: medium

Source section: accessibility-shouldnt-be-an-extra

Item 4

Claim: Constraints aren't necessarily a problem; they need to be understood early enough to plan around them.

Evidence type: page_content

Evidence strength: medium

Source section: be-open-about-whats-already-decided

Item 5

Claim: A sitemap is more useful than page count for understanding the website's main areas and content types.

Evidence type: page_content

Evidence strength: medium

Source section: give-us-an-idea-of-what-the-website-needs-to-contain

Item 6

Claim: Length of a brief is not a good indicator of how useful it will be.

Evidence type: page_content

Evidence strength: medium

Source section: a-brief-is-the-beginning-not-the-finished-plan

Item 7

Claim: A rough budget indication helps ensure proposals are realistic.

Evidence type: page_content

Evidence strength: medium

Source section: talk-about-budget

Services

Website architecture & integrations

Relationship: supporting

Url: /services/website-architecture-integrations/

Digital planning & research

Relationship: primary

Url: /services/digital-planning-research/

UX design & user experience

Relationship: supporting

Url: /services/ux-design-user-experience/

Information architecture

Relationship: supporting

Url: /services/information-architecture/

Website design & build

Relationship: supporting

Url: /services/website-design-build/

Sections

Overview

Key points

Content

Item 1

Text: If you’re planning a new website, writing the brief can sometimes feel like a project in itself. What pages will it need? Which features should you specify? Do you need to know the CMS? Should you have the whole sitemap worked out before speaking to an agency? In our experience, you really don’t. A useful website brief isn’t one that has every answer. It’s one that gives us a good understanding of your organisation, what you’re trying to achieve and any important requirements we need to know about. The rest is something we can work through together.

Start with why the website needs to change

Key points

Content

Item 1

Text: One of the most useful things you can tell us is why you’re looking at the website in the first place. Perhaps the existing site has become difficult to manage. It might no longer reflect the organisation. Performance could be poor, people may struggle to find what they need or years of adding content and functionality may have made everything harder than it needs to be. Sometimes there isn’t an existing website at all. Whatever the situation, knowing the problems you’re trying to solve is often more useful than receiving a long list of proposed features. “We need an events calendar” gives us a requirement. “We run hundreds of events each year and people struggle to find the ones relevant to them” gives us a problem we can start solving. That distinction matters. If you have website analytics, search data, feedback from users or information about common support enquiries, these can be useful too. They might show which parts of the website people use most, where they’re struggling or what they’re searching for. You don’t need to analyse everything before approaching an agency. Knowing that the information exists gives us something useful to explore during discovery.

Tell us who the website is for

Content

Item 1

Text: You probably know much more about the people using your website than you realise. Who are they? Why are they coming to you? What are they usually trying to find or do? Are there particularly important groups with very different needs? You don’t necessarily need detailed personas or user journeys at this stage. If that work hasn’t been done, it can form part of discovery. What matters is that we’re not designing around an abstract idea of a “website user”. Understanding the people using a website, what they’re trying to achieve and the problems they currently experience is a fundamental part of discovery. It also helps us question assumptions before they become expensive functionality.

Be open about what’s already decided

Content

Item 1

Text: Most website projects have some fixed parts. There might be an existing brand to follow, systems the website needs to connect with or technology your IT team already supports. Your organisation might have specific security, data protection, hosting or accessibility requirements. There may also be internal deadlines, procurement requirements or budgets that affect what’s realistic. Put them in the brief. Constraints aren’t necessarily a problem. We just need to understand them early enough to plan around them. It’s just as useful to tell us what hasn’t been decided. If you don’t know which CMS you need, for example, you don’t need to choose one simply to complete the brief. Tell us what your team needs to be able to manage and we can work out the most appropriate technical approach from there.

What if you’re preparing a formal tender?

Content

Item 1

Text: Some organisations need to follow a formal procurement process when commissioning a website. This might involve a detailed specification, defined requirements and evaluation criteria that suppliers must respond to. That’s understandable, particularly where public funding, governance or internal approval processes are involved. Even with a formal tender, though, it’s useful to explain the problems you’re trying to solve rather than prescribing every part of the finished website. Where requirements are fixed, make that clear. Where there’s room for suppliers to recommend an approach, allowing some flexibility can lead to better solutions. A good specification gives agencies enough information to prepare an accurate proposal while leaving room for their experience and recommendations.

You don’t need to design the solution

Content

Item 1

Text: This is probably the biggest thing we’d change about a lot of website briefs we see. It’s very easy to start specifying the finished website before any discovery has happened. A brief might ask for a particular navigation structure, search system, interactive map, account area or integration. Sometimes those things are necessary. Sometimes they’re a proposed solution to a problem that could be solved much more simply. We’re much more interested in understanding the need behind them. If people need to find the right course from hundreds of options, tell us that. If different teams need to manage their own content without affecting other areas of the website, tell us that. If staff are currently copying information between two systems every week, definitely tell us that. Those are useful requirements. The exact interface or technical solution can come later.

Give us an idea of what the website needs to contain

Content

Item 1

Text: Page count can be useful, but it doesn’t tell us much on its own. A website with a thousand pages might be built around a relatively small number of repeatable content types and on-page features. Another with 30 pages could have very different requirements on almost every page. A sitemap is much more useful. It gives us an idea of the website's main areas, how they relate to each other, and the types of content we’re likely to work with. We don’t expect this to be final. Part of discovery is working through the structure and deciding how different types of content should work. If you have courses, events, people, projects or resources, for example, we can help work out what information each needs and how those content types connect across the website. It's also helpful to know any specific requirements you already have. For example, courses may need to pull information from another system. Events need filtering by location and audience. Certain resources should only be available to logged-in users. You might need an interactive tool, searchable directory, map or something very specific to the way your organisation works. You don’t need to have designed those features. Knowing what people need to be able to do gives us something to explore properly during discovery. If you already have a sitemap, content audit, analytics, user research or other useful information, send that too. It doesn’t need packaging neatly into the brief. We’d rather know it’s there and decide together what’s useful.

Talk about budget

Key points

Content

Item 1

Text: Nobody particularly enjoys this bit. But even a rough budget indication helps. It isn’t about finding out how much money we can spend. It’s about making sure we’re proposing something realistic. There can be several technically valid ways of approaching the same problem. Knowing the available budget helps us decide where bespoke functionality adds value, where a simpler solution might work just as well and what should perhaps wait for a later phase. The same applies to timescales. If the website has to launch before the start of an academic year, a major event or the end of an existing contract, that’s important. If there isn’t a fixed deadline, that’s useful to know too.

Don’t forget the people managing it

Key points

Content

Item 1

Text: A website has two groups of people to consider: those using it and those responsible for keeping it running. The second group sometimes gets forgotten. Tell us who will manage the website once it’s live. Is there a dedicated web team? Will lots of people contribute content? Do they have different responsibilities or permissions? Does everything need central approval? We’ve always believed that a good website should work just as well behind the scenes as it does at the front. If publishing a news story requires somebody to understand HTML, or changing a landing page means calling the agency every time, something has probably gone wrong. Knowing how your team works helps us design the editing experience around them too.

Accessibility shouldn’t be an extra

Content

Item 1

Text: Accessibility is worth mentioning explicitly, particularly if your organisation has specific standards or regulatory requirements. For UK public sector organisations, websites and mobile applications are subject to accessibility regulations, including requirements to make services accessible and publish an accessibility statement. WCAG 2.2 is also the current standard used in UK government accessibility guidance. But accessibility shouldn’t only appear in a brief because there’s a compliance requirement. Whoever your audience is, considering accessibility from the beginning generally leads to a website that’s easier for more people to use. For us, WCAG 2.2 AA is a baseline for our website work rather than something we bolt on at the end.

What should actually go in the brief?

Items

Content

Item 1

Text: There isn’t one perfect template. For most projects, we’d rather receive ten useful pages than fifty pages of requirements nobody is completely sure about. As a starting point, we’d want to understand: And if you don’t know some of those things yet, that’s fine.

A brief is the beginning, not the finished plan

Content

Item 1

Text: The best briefs give everyone somewhere useful to start. They help us understand what you know, what you need and where there are still questions to answer. From there, discovery, research and conversations with the people involved can turn that starting point into a proper plan for the website. We’ve worked on projects where the initial brief was extremely detailed and others where it was only a few pages long. Length has never been a particularly good indicator of how useful it will be. Tell us about your organisation, what isn’t working, what the website needs to do and anything you already know you’ll need. We can help with the website bit.

Entities

Website brief

Content audit

WCAG 2.2 AA

User needs

Discovery

Sitemap

Concept relationships

Item 1

Subject: Understanding user needs

Predicate: helps inform

Object: website functionality and design decisions

Item 2

Subject: Website brief

Predicate: should explain

Object: business objectives and reasons for the project

Item 3

Subject: Website brief

Predicate: should document

Object: existing requirements and project constraints

Item 4

Subject: WCAG 2.2 AA

Predicate: is the accessibility baseline for

Object: Feel Created website projects

Item 5

Subject: Website brief

Predicate: should outline

Object: content types and functionality requirements

Item 6

Subject: Website brief

Predicate: should identify

Object: audience needs and problems to solve

Item 7

Subject: Discovery

Predicate: helps determine

Object: appropriate website solutions

Implementation patterns

Item 1

Pattern: Content and functionality assessment

Description: Provide an overview of the website's main areas, content types and functionality. Existing sitemaps, content audits and other supporting information can help establish the requirements.

Benefit: Helps the agency understand the likely complexity of the website and identify opportunities for reusable content and functionality.

Item 2

Pattern: Early identification of requirements and constraints

Description: Share existing decisions, technical requirements, budgets, deadlines and organisational constraints, while identifying areas that remain undecided.

Benefit: Supports realistic project planning and allows alternative approaches to be explored where appropriate.

Item 3

Pattern: Discovery-led project planning

Description: Use the initial brief as a starting point for further discussion, research and planning rather than treating it as a complete technical specification.

Benefit: Allows requirements and proposed solutions to be reviewed before detailed design and development begin.

Item 4

Pattern: Problem-led website brief

Description: Explain why the website needs to change and describe the problems people experience rather than prescribing features or technical solutions.

Benefit: Helps the agency understand the underlying requirements and explore appropriate solutions during discovery.

Item 5

Pattern: Audience-focused planning

Description: Identify the main audiences, what they need from the website and any difficulties they currently experience. Detailed user research can follow during discovery.

Benefit: Helps ensure the website is planned around audience needs rather than assumptions.

Practical guidance

Item 1

Guidance: Identify existing decisions and constraints, including branding, systems, security, accessibility, deadlines and procurement requirements. Explain what remains undecided.

Importance: high

Item 2

Guidance: Describe the main audiences, what they need from the website and any difficulties they currently experience. Detailed user research can form part of discovery.

Importance: high

Item 3

Guidance: Provide an outline of the website's main areas, content types and functionality. An existing sitemap can help, but it doesn't need to be final.

Importance: high

Item 4

Guidance: Share any existing sitemaps, content audits, analytics or user research to support discovery, even if these materials are incomplete.

Importance: medium

Item 5

Guidance: Explain why the website needs to change, focusing on the problems to solve rather than prescribing features or technical solutions.

Importance: high

Item 6

Guidance: Explain who will manage the website after launch, including content editing responsibilities, permissions and approval processes.

Importance: high

Item 7

Guidance: Include accessibility requirements from the beginning, particularly where specific standards or public sector regulations apply.

Importance: high

Item 8

Guidance: Share an indicative budget and any important timescales so the agency can recommend realistic solutions and priorities.

Importance: high

Risk areas

Item 1

Risk: Failing to identify existing requirements and constraints

Impact: May result in unrealistic proposals, unexpected technical challenges or delays during development.

Item 2

Risk: Overlooking the needs of people managing the website

Impact: May result in complicated content management processes, unnecessary administrative work or continued reliance on an agency for routine updates.

Item 3

Risk: Not communicating budget or timescale expectations

Impact: May lead to proposals that exceed available resources or cannot realistically be delivered within the required timeframe.

Item 4

Risk: Prescribing technical solutions before discovery

Impact: May result in unnecessary functionality, increased costs or solutions that don't adequately address the underlying problem.

Item 5

Risk: Treating accessibility as an afterthought

Impact: May result in accessibility barriers, additional remediation costs and potential regulatory compliance issues.

Item 6

Risk: Not understanding audience needs

Impact: May lead to a website designed around assumptions rather than what people need to find or accomplish.

Common misconceptions

Item 1

Misconception: A website brief should specify exactly which features and technical solutions need to be built.

Clarification: Explaining the problems people experience and what the website needs to achieve can be more useful than prescribing specific features. Discovery helps determine the most appropriate solutions.

Item 2

Misconception: A website brief must contain every answer before approaching an agency.

Clarification: A useful brief explains the organisation's objectives, audience needs and important requirements. Decisions about the CMS, sitemap and technical solutions can be explored during discovery.

Item 3

Misconception: Page count is a reliable indicator of website complexity.

Clarification: Page count alone doesn't reflect complexity. A website with thousands of pages may use a small number of repeatable content types, while a much smaller website could require extensive bespoke functionality. Understanding the sitemap, content types and requirements provides a more useful starting point.

Item 4

Misconception: A longer website brief is necessarily more useful.

Clarification: The value of a brief depends on the information it provides, not its length. Ten pages explaining the organisation's objectives, problems and requirements can be more useful than fifty pages of uncertain specifications.

Technical context

Accessibility standards: WCAG 2.2 AA

Regulatory requirements: UK public sector website accessibility regulations

Integrations: Examples of potential website requirements include integrations with external course information systems, event filtering, restricted content for logged-in users, searchable directories, interactive maps and other custom functionality.

Reasoning paths

Item 1

User problem: Briefs may be too detailed or too vague, with length not indicating usefulness

Evidence refs

Relevant sections

Item 2

User problem: Accessibility is sometimes treated as an afterthought rather than a baseline

Evidence refs

Relevant sections

Item 3

User problem: Organisations may not know what to include in a website brief

Evidence refs

Relevant sections

Item 4

User problem: Years of adding content and functionality made things harder

Evidence refs

Relevant sections

Related links

Item 1

Text: We can help with the website bit

Url: /contact/

Source section: a-brief-is-the-beginning-not-the-finished-plan

Content profile

Content type: Insight article

Primary topic: How to write a useful website brief for a new website or redevelopment project.

Supporting topics

Primary audience

Retrieval topics

Organisation

Name: Feel Created

Type: Digital partner specialising in websites and digital platforms

Url: https://www.feelcreated.com/

Service model: We work as an extension of our clients' teams, combining strategy, UX, accessibility, content design, WordPress development and ongoing support to create digital platforms that help organisations communicate more clearly, work more efficiently and grow sustainably.