Write a Website Project Brief With Measurable Goals
A website brief that only lists pages and a launch date leaves success undefined. Here is how to write measurable goals into the brief—purpose, a few outcomes, and metrics you can check after launch—drawing on UK service planning guidance and US digital-experience policy.
A website project often starts with a list of pages, a preferred look, and a launch window. That material is useful, but it does not say how anyone will know the site worked. When the brief never states a measurable goal, the team can ship on time and still disagree about whether the project succeeded.
This article treats the project brief as the place where you define success before design begins. It draws on the UK government’s Service Manual guidance for setting performance metrics and planning with measurable objectives, and on US federal digital-experience policy that expects websites to be designed with users and data in view—not only with a finished visual package.
Why a page list is not a brief
A page inventory answers what the site will contain. A brief should also answer what change the site is supposed to produce. Without that second half, design debates stay aesthetic: which layout looks better, which homepage feels more “premium,” which color feels more on brand. Those questions matter, but they are hard to settle when nobody wrote down what the site is for.
- Purpose names the job. Why does this site exist for the people who visit it and for the business that runs it?
- Goals name the outcomes. What should improve if the project works—more qualified inquiries, fewer support calls about basic information, faster booking, clearer service choice?
- Metrics make goals checkable. What number or evidence will you look at, against what baseline, and by when?
What goes wrong when goals stay vague
- Launch equals success. The project is judged by whether it shipped, not by whether visitors could do what they came to do.
- Scope expands without a filter. Extra pages and features get added because nothing in the brief says which outcomes they serve.
- Post-launch review has nothing to measure. Six months later, nobody can say whether the redesign moved the needle, because the needle was never named.
How government service guidance structures measurable success
The UK government’s Service Manual, in How to set performance metrics for your service (published 5 December 2017), starts from purpose rather than from a dashboard of available analytics. Service owners are told to sum up why the service exists in a single line, then derive a small number of “benefits”—short descriptions of outcomes that contribute to that purpose, based on user needs.
From each benefit, the guidance asks teams to write a hypothesis in a fixed shape: doing or changing something will lead to a benefit because of a stated assumption. Only then do they decide what to measure. As the service evolves, the Manual recommends choosing three or four metrics that would answer a blunt question: is this service working? Other metrics can stay inside the team for detail; the shared KPIs stay few.
Context is treated as part of the metric, not an optional extra. Teams are told to establish a baseline of current performance across channels, measure continuously rather than in isolated snapshots, and set targets for a specific future point. The Manual’s example is concrete: in six months, you might expect a 10% reduction in the time it takes a user to make an application after simplifying the process. Digital analytics are one data source among others—user feedback, call-centre data, and financial information are listed alongside web analytics—and metrics are meant to be combined with user research, not used alone.
Planning with a few objectives, not a feature wishlist
A related Service Manual page, Planning in agile (first published 16 February 2016; updated 31 March 2026), describes a simple planning sequence: decide on a vision, make objectives, then make a roadmap. For objectives, it recommends defining three to five main ones, and for each objective defining three to four results you can measure with quantitative data. The roadmap typically looks six to twelve months ahead and is revisited as the team learns.
For a business website brief, that sequence translates cleanly. The vision is the one-line purpose. The objectives are the outcomes the site must support. The measurable results are the metrics you will check. The roadmap is the phased work—launch contents first, then the improvements that depend on early evidence—not a pile of features ordered by preference.
What US digital-experience policy adds for private projects
US federal policy is aimed at agencies, but the measurement categories it uses are useful when a private studio or business owner wants a brief that will still make sense after launch. In September 2023, the Office of Management and Budget issued memorandum M-23-22, Delivering a Digital-First Public Experience. Digital.gov summarizes the memo’s requirements for websites and digital services, including that they be user-centered and data-driven.
A September 2024 Digital.gov article from the U.S. General Services Administration describes how OMB organizes that guidance into digital-experience pillars. The Analytics pillar pairs participation in government-wide analytics with collecting feedback from customers, with the intended outcome of optimized digital experiences based on insights into user behavior. The same article cites an OMB fact sheet (as of September 2023) reporting that 45% of federal websites were not mobile-friendly, 60% had a possible accessibility issue, and 80% did not use the U.S. Web Design System—figures that show why policy treats measurable foundations as part of delivery, not as optional polish.
Performance.gov’s Federal Website Performance snapshot (data current as of November 2024) groups foundational expectations into categories such as Accessibility, Analytics, Feedback, Mobile-Friendliness, Search Optimization, Security, and Design Consistency. A business site brief does not need to copy federal scoring. It does need enough of the same discipline: decide which categories matter for this project, and write them as goals you can check.
“A brief that only lists pages describes a product. A brief that names outcomes and metrics describes a decision the site is supposed to support.”
— Windware Studio Practice Note
A brief checklist you can fill before design
Use this as a one-page addendum to your existing materials list. Keep the numbers few enough that the whole team can remember them.
- Purpose in one sentence: Who the site serves and what it must help them do.
- Three to five outcome goals: Changes you expect if the project works (for example, more complete inquiry forms, fewer “what do you offer?” calls, clearer path to book a consultation).
- One hypothesis per goal: What you will change, what benefit you expect, and why you think that link holds.
- Three or four shared metrics: The measures that answer “is the website working?” after launch.
- Baseline and review date: Where each metric stands now (or how you will establish it), and when you will look again.
- Data sources named: Analytics events, form submissions, call logs, sales notes, or a short user feedback method—not “we’ll check the numbers” without saying which numbers.
- Out of scope: Features or pages that do not serve a listed goal for this phase.
| Brief element | Weak version | Stronger version |
|---|---|---|
| Purpose | “Modernize the website” | “Help prospective clients understand our three services and request a consultation” |
| Goal | “Get more traffic” | “Increase completed consultation requests from the services pages” |
| Metric | “Engagement” | “Consultation form completions per month, with a baseline from the last six months” |
| Review | “After launch” | “Compare the baseline to the same metric at 90 days” |
Limitation worth stating in the brief
Metrics will not explain why something moved. The Service Manual is explicit that analysis should say what happened, why it happened, and what to do next, and that metrics should sit beside user research. A rise in form starts that never become submissions still needs observation or interviews. Write that limit into the brief so nobody treats a dashboard as a substitute for talking to people.
Practical takeaways for your next website project
- Put purpose and goals above the page list. Pages are how you deliver outcomes; they are not the outcomes.
- Cap shared goals and metrics. Three to five objectives, and roughly three or four metrics everyone watches, match the Service Manual’s scale and stay usable in a small business.
- Write the measurement method while the brief is still editable. If you cannot name a data source and a baseline, the goal is not ready.
- Include one foundation goal if it is currently broken. Mobile usability, a working feedback path, or basic analytics coverage can be legitimate brief items when they are missing—Performance.gov treats those as delivery expectations, not decorations.
- Schedule the review in the brief. A goal without a date tends to dissolve into “we’ll know it when we see it.”
Ready to Discuss Your Website?
If you are planning a new website, a service redesign, or custom development for your business, we’re here to help shape the work.
- Explore Our Services: Web Design · Web Development · Website Redesign
- Start a Conversation: Tell us about your project via our Contact Form or email us directly at
[email protected].