If your organisation is thinking “we probably need to start planning for a new website next year,” you’re not alone.
After 2025, a lot of schools, councils, and community organisations are in the same spot: the website still kind of works, but staff are tired, pages are messy, and every meeting ends with someone saying, “we just need a modern refresh.”
Here’s the sitch: most website briefs we see do not match the real problems underneath. They talk about “fresh design” and “clean layout” when the real issues live in the CMS, the structure, the hosting, and the way staff have to wrestle the thing just to publish a term date.
If those are not addressed, then you will have a new website with a bunch of new problems.
This guide is about fixing that gap and using the issues of your current site as data.
It’s not about writing a prettier brief. It’s about writing one that actually matches how your website needs to work over the next 5–7 years.
Why a lot of briefs miss the point
For most organisations, the website brief goes wrong before it’s even drafted.
1. The wrong person gets handed the problem
The person asked to manage the website is usually already carrying five other jobs: comms, marketing, stakeholder updates, events, or all of the above.
They’re smart, capable, and under pressure.
What they’re not given is time for proper discovery.
So the brief leans on what’s visible:
- “It looks dated.”
- “It’s not mobile-friendly.”
- “We need better SEO.”
All fair observations. None of them explain why the system underneath feels stuck.
2. Procurement templates ask the wrong questions
Standard templates love:
- number of pages
- design concepts
- feature wishlists
- SEO rankings
They rarely ask about:
- what the website needs to do and do well
- how often staff need to update content
- who actually logs in
- what’s breaking behind the scenes
- where processes rely on workarounds or manual effort
You end up with three or more quotes, all priced insanely differently and you have no idea who to go with.
3. Past projects make teams cautious
If you’ve already had one rough website project, it’s very normal to aim small.
Instead of saying “we think the whole back end is holding us back”, the brief asks for:
- “a tidy-up of our existing site”
- “updated look and feel”
The outcome: your team spends money, time, and energy… and hits the same pain points again two years later.
The 5 brief traps we see all the time
Here’s how typical requests show up, and what’s usually sitting underneath.
1. “We need a modern design”
What you’re seeing:
The site looks old, staff are embarrassed to send people there, leadership wants it to “feel current.”
What’s usually happening underneath:
- nobody has time or access to update content
- templates are rigid, so everything feels the same
- the CMS is so clunky that people avoid it
What your brief actually needs to say:
“We need a website our team can keep current without developer support.”
2. “Make it mobile-friendly”
What you’re seeing:
People complain they can’t use forms on their phone. Menus are fiddly. Tables don’t scale.
What’s usually happening underneath:
- it’s built on older tech that never really supported mobile well
- content was laid out for desktop first, then squeezed down
- key tasks (bookings, forms, portals) were never tested on mobile
What your brief actually needs to say:
“Rebuild on modern, responsive templates with mobile-first layouts for high-use tasks.”
3. “Improve our SEO”
What you’re seeing:
You’re not showing up reliably for key searches. People can’t find basic information through Google. Your competitors are ranking higher than you.
What’s usually happening underneath:
- important content is locked in PDFs
- there’s no clear content hierarchy
- you don’t have control over titles, descriptions, or slugs
What your brief actually needs to say:
“Give us a clear structure and proper control over how content appears in search.”
4. “We’re worried about security”
What you’re seeing:
There’s a general sense of risk: old plugins, unknown hosting, no one quite sure when anything was last updated.
What’s usually happening underneath:
- shared hosting still in place from launch
- CMS version creeping toward end-of-support
- no clear process for updates, monitoring, or backups
What your brief actually needs to say:
“Move us onto secure hosting with clear responsibilities for updates, backups, and incident response.”
5. “We just want it to be easy to update”
What you’re seeing:
Staff send Word documents to “whoever knows how to use the CMS.” Nobody else goes near it.
What’s usually happening underneath:
- training never really happened
- templates don’t match real workflows
- roles and permissions are messy or non-existent
What your brief actually needs to say:
“We need an editing experience that matches how our team actually works, with training and permissions to back it up.”
How to find the real problem before you put the brief together
Before you write a single line of scope, do a quick internal review. It doesn’t need to be fancy.
1. Ask the people who use the website daily
Talk to staff who add news, update pages, upload documents, manage forms.
Ask them:
- What takes the longest?
- What do you avoid doing because it’s too hard?
- Where do you use workarounds outside the website?
2. Look at your community feedback
Scan call logs, emails, and helpdesk tickets from the past few months.
Note patterns like:
- “I can’t find…”
- “The form doesn’t work on my phone”
- “I can’t download this document”
Those patterns tell you where the structure is failing.
3. Capture the basics of your tech
You don’t need to be technical. Just document:
- what CMS you’re on and what version
- what kind of hosting you’re using (shared or VPS)
- roughly how many plugins/add-ons you rely on
This is enough context for any decent agency to have an honest conversation with you.
What a strong brief covers
Once you understand your reality, the brief becomes much easier to write.
Start with outcomes, not aesthetics
Instead of:
“Modern, clean website with 15 pages”
Try:
- “Reduce calls to reception by making key information easy to find online”
- “Make it possible for non-technical staff to update core pages weekly”
That gives everyone something concrete to design around.
Be honest about current pain
Include statements like:
- “Staff avoid logging into the CMS because it feels slow and confusing”
- “Parents regularly call to find term dates and excursion details”
- “We can’t safely update the CMS without developer support”
This doesn’t make you look bad.
It makes your brief useful.
Name your users clearly
Outline who will use the system:
- reception and admin staff
- marketing or comms
- leadership and board
- external users: parents, clients, donors, community
For each, note the key tasks they need to complete.
Talk about constraints
If you know:
- budget bands
- timeframes (eg funding windows, enrolment periods)
- existing systems you must keep
Include them. That context is practical, not “oversharing.”
A simple checklist for your 2026 website brief
Use this as a quick run-through before you send anything out.
Goals & outcomes
- We’ve written clear outcomes beyond “modern design" and "mobile design"
- We know what success looks like in 12–24 months
- We’ve named the audiences the website serves
Staff and workflow
- We understand who updates what, and how often
- We’ve captured what currently slows staff down
- We’ve listed training and permission needs
Technical reality
- We know our current CMS and version
- We know whether we’re on shared hosting or VPS
- We’ve listed critical integrations (forms, payments, portals)
Content and structure
- We know where our most-used content lives
- We’ve identified cluttered or confusing areas
- We’ve flagged any heavy reliance on PDFs
Lifecycle and timing
- We know roughly when the site was last rebuilt
- We’ve checked CMS end-of-support timelines
- We’ve considered whether we’re in Maintain, Update, Refresh, or Rebuild territory
You don’t have to get every detail perfect.
You just need enough clarity that anyone reading your brief can see the real picture.
