{ "meta": { "type": "insight_article", "language": "en-GB", "last_updated": "2026-10-16", "ai_endpoint": "/insights/what-makes-a-useful-website-brief/ai.json", "source_page": "/insights/what-makes-a-useful-website-brief/" }, "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": [ "Marketing managers and communications teams", "Website and digital project managers", "Universities, colleges and education providers", "Public sector and charity organisations", "Organisations planning a website redesign or redevelopment" ], "problems_solved": [ "Existing website difficult to manage", "Website no longer reflects the organisation", "Poor performance", "People struggle to find what they need", "Years of adding content and functionality made things harder", "Organisations may not know what to include in a website brief", "Briefs may be too detailed or too vague, with length not indicating usefulness", "People managing the website after launch are often forgotten" ] }, "page": { "title": "What makes a useful website brief?", "slug": "what-makes-a-useful-website-brief", "url": "/insights/what-makes-a-useful-website-brief/", "canonical_url": "https://www.feelcreated.com/insights/what-makes-a-useful-website-brief/", "status": "published" }, "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": [ "Marketing managers and communications teams", "Website and digital project managers", "Universities, colleges and education providers", "Public sector and charity organisations", "Organisations planning a website redesign or redevelopment" ] }, "topics": [ "How to write a useful website brief for a new website or redevelopment project.", "Website brief", "Discovery", "User needs", "Constraints", "Content types", "Accessibility", "Discovery phase", "User research", "Accessibility regulations", "WCAG 2.2" ], "content_focus": [ "Website brief preparation", "Discovery and planning", "User needs and audience understanding", "Constraints and requirements", "Problem-solving over feature specification", "Budget and timescale considerations", "Content and functionality requirements", "Accessibility and regulatory compliance", "Content management and editing experience" ], "canonical_claims": [ { "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", "id": "claim-001" }, { "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", "id": "claim-002" }, { "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", "id": "claim-003" }, { "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", "id": "claim-004" }, { "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", "id": "claim-005" }, { "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", "id": "claim-006" }, { "claim": "A rough budget indication helps ensure proposals are realistic.", "evidence_type": "page_content", "evidence_strength": "medium", "source_section": "talk-about-budget", "id": "claim-007" } ], "services": [ { "name": "Website architecture & integrations", "relationship": "supporting", "url": "/services/website-architecture-integrations/" }, { "name": "Digital planning & research", "relationship": "primary", "url": "/services/digital-planning-research/" }, { "name": "UX design & user experience", "relationship": "supporting", "url": "/services/ux-design-user-experience/" }, { "name": "Information architecture", "relationship": "supporting", "url": "/services/information-architecture/" }, { "name": "Website design & build", "relationship": "supporting", "url": "/services/website-design-build/" } ], "sections": [ { "id": "overview", "heading": "Overview", "type": "introduction", "key_points": [ "In our experience, you really don’t.", "A useful website brief isn’t one that has every answer." ], "content": [ { "type": "paragraph", "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." } ] }, { "id": "start-with-why-the-website-needs-to-change", "heading": "Start with why the website needs to change", "type": "section", "key_points": [ "Perhaps the existing site has become difficult to manage.", "It might no longer reflect the organisation." ], "content": [ { "type": "paragraph", "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." } ] }, { "id": "tell-us-who-the-website-is-for", "heading": "Tell us who the website is for", "type": "section", "content": [ { "type": "paragraph", "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." } ] }, { "id": "be-open-about-whats-already-decided", "heading": "Be open about what’s already decided", "type": "section", "content": [ { "type": "paragraph", "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." } ] }, { "id": "what-if-youre-preparing-a-formal-tender", "heading": "What if you’re preparing a formal tender?", "type": "section", "content": [ { "type": "paragraph", "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." } ] }, { "id": "you-dont-need-to-design-the-solution", "heading": "You don’t need to design the solution", "type": "section", "content": [ { "type": "paragraph", "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." } ] }, { "id": "give-us-an-idea-of-what-the-website-needs-to-contain", "heading": "Give us an idea of what the website needs to contain", "type": "section", "content": [ { "type": "paragraph", "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." } ] }, { "id": "talk-about-budget", "heading": "Talk about budget", "type": "section", "key_points": [ "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." ], "content": [ { "type": "paragraph", "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." } ] }, { "id": "dont-forget-the-people-managing-it", "heading": "Don’t forget the people managing it", "type": "section", "key_points": [ "The second group sometimes gets forgotten.", "Tell us who will manage the website once it’s live.", "Will lots of people contribute content?" ], "content": [ { "type": "paragraph", "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." } ] }, { "id": "accessibility-shouldnt-be-an-extra", "heading": "Accessibility shouldn’t be an extra", "type": "section", "content": [ { "type": "paragraph", "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." } ] }, { "id": "what-should-actually-go-in-the-brief", "heading": "What should actually go in the brief?", "type": "section", "items": [ "your organisation and what it does", "why the project is happening", "what isn’t working at the moment", "what you want the new website to achieve", "the main groups of people who will use it", "important content and functionality", "existing systems or integrations", "accessibility, security or technical requirements" ], "content": [ { "type": "paragraph", "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." } ] }, { "id": "a-brief-is-the-beginning-not-the-finished-plan", "heading": "A brief is the beginning, not the finished plan", "type": "section", "content": [ { "type": "paragraph", "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": [ { "name": "Website brief", "type": "Topic" }, { "name": "Content audit", "type": "Deliverable" }, { "name": "WCAG 2.2 AA", "type": "Standard" }, { "name": "User needs", "type": "Concept" }, { "name": "Discovery", "type": "Process" }, { "name": "Sitemap", "type": "Deliverable" } ], "concept_relationships": [ { "subject": "Understanding user needs", "predicate": "helps inform", "object": "website functionality and design decisions" }, { "subject": "Website brief", "predicate": "should explain", "object": "business objectives and reasons for the project" }, { "subject": "Website brief", "predicate": "should document", "object": "existing requirements and project constraints" }, { "subject": "WCAG 2.2 AA", "predicate": "is the accessibility baseline for", "object": "Feel Created website projects" }, { "subject": "Website brief", "predicate": "should outline", "object": "content types and functionality requirements" }, { "subject": "Website brief", "predicate": "should identify", "object": "audience needs and problems to solve" }, { "subject": "Discovery", "predicate": "helps determine", "object": "appropriate website solutions" } ], "implementation_patterns": [ { "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." }, { "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." }, { "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." }, { "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." }, { "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": [ { "guidance": "Identify existing decisions and constraints, including branding, systems, security, accessibility, deadlines and procurement requirements. Explain what remains undecided.", "importance": "high" }, { "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" }, { "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" }, { "guidance": "Share any existing sitemaps, content audits, analytics or user research to support discovery, even if these materials are incomplete.", "importance": "medium" }, { "guidance": "Explain why the website needs to change, focusing on the problems to solve rather than prescribing features or technical solutions.", "importance": "high" }, { "guidance": "Explain who will manage the website after launch, including content editing responsibilities, permissions and approval processes.", "importance": "high" }, { "guidance": "Include accessibility requirements from the beginning, particularly where specific standards or public sector regulations apply.", "importance": "high" }, { "guidance": "Share an indicative budget and any important timescales so the agency can recommend realistic solutions and priorities.", "importance": "high" } ], "risk_areas": [ { "risk": "Failing to identify existing requirements and constraints", "impact": "May result in unrealistic proposals, unexpected technical challenges or delays during development." }, { "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." }, { "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." }, { "risk": "Prescribing technical solutions before discovery", "impact": "May result in unnecessary functionality, increased costs or solutions that don't adequately address the underlying problem." }, { "risk": "Treating accessibility as an afterthought", "impact": "May result in accessibility barriers, additional remediation costs and potential regulatory compliance issues." }, { "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": [ { "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." }, { "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." }, { "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." }, { "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": [ { "user_problem": "Briefs may be too detailed or too vague, with length not indicating usefulness", "evidence_refs": [ "claim-006", "claim-001" ], "relevant_sections": [ "a-brief-is-the-beginning-not-the-finished-plan", "tell-us-who-the-website-is-for", "what-if-youre-preparing-a-formal-tender" ] }, { "user_problem": "Accessibility is sometimes treated as an afterthought rather than a baseline", "evidence_refs": [ "claim-003" ], "relevant_sections": [ "what-should-actually-go-in-the-brief", "be-open-about-whats-already-decided", "accessibility-shouldnt-be-an-extra" ] }, { "user_problem": "Organisations may not know what to include in a website brief", "evidence_refs": [ "claim-001", "claim-006" ], "relevant_sections": [ "overview", "what-should-actually-go-in-the-brief", "a-brief-is-the-beginning-not-the-finished-plan" ] }, { "user_problem": "Years of adding content and functionality made things harder", "evidence_refs": [ "claim-005" ], "relevant_sections": [ "start-with-why-the-website-needs-to-change", "what-should-actually-go-in-the-brief", "give-us-an-idea-of-what-the-website-needs-to-contain" ] } ], "related_links": [ { "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": [ "Website brief", "Discovery", "User needs", "Constraints", "Content types", "Accessibility" ], "primary_audience": [ "Marketing managers and communications teams", "Website and digital project managers", "Universities, colleges and education providers", "Public sector and charity organisations", "Organisations planning a website redesign or redevelopment" ] }, "retrieval_topics": [ "How to write a useful website brief for a new website or redevelopment project.", "Website brief", "Discovery", "User needs", "Constraints", "Content types", "Accessibility", "Discovery phase", "User research", "Accessibility regulations", "WCAG 2.2", "Website project planning" ], "organisation": { "name": "Feel Created", "url": "https://www.feelcreated.com/", "type": "Digital partner specialising in websites and digital platforms", "specialisms": [ "Digital strategy and planning", "User experience (UX) design", "Accessibility and inclusive design", "WordPress design and development", "Content strategy and information architecture", "AI-ready structured content", "AI Features & Integrations", "Search optimisation and technical SEO", "Website performance optimisation", "Website security and technical governance", "Platform architecture and integrations", "Content management systems", "Digital audits and reviews", "Creative and marketing support", "Website maintenance and support" ], "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." } }