How to Write a Useful Website Brief • Feel Created

Overview

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

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

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

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?

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

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

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

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

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

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?

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:

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
who’s involved in the project and decision-making
approximate scale and existing content
budget and timescales
anything that’s already been decided
anything you’re particularly unsure about

And if you don’t know some of those things yet, that’s fine.

A brief is the beginning, not the finished plan

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.