A website specification is the document that tells suppliers what a business expects from its future site. Most of the ones we come across describe a solution: a site map, a list of pages, features seen elsewhere. The best describe a problem — whom the business wants to convince, of what, and how it will know it has succeeded — and leave suppliers to propose how to answer it.
The difference is not one of style. A document that describes the solution gets quotes that price that solution, good or bad. A document that describes the problem gets proposals that can be compared on how they solve it — which is exactly what needs comparing.
What a specification is really for
A specification serves three purposes, and a document that neglects one fails on all three.
- Make the responses comparable. Every supplier answers the same question. Without it, each imagines its own project, and quotes can only be compared on their totals — which says nothing.
- Set what will be received. The document says how the work will be recognised as done. It is what gets reread on delivery, and what settles a disagreement.
- Guard against interpretation. Whatever is not written down will be interpreted, and rarely in favour of whoever is paying.
What it is not should be said too. It is not a dictated site map, nor a catalogue of features spotted at competitors, nor a sixty-page document nobody will read to the end. “We want a blog” describes a solution. “Our customers always ask us the same questions before buying, and we want them to find the answers without calling us” describes a problem — to which a blog may or may not be the answer.
Whatever is not written down will be interpreted, and rarely in favour of whoever is paying.
The method: writing it in four stages
A specification is not written in one go. It is built in four stages, and the first is not writing.
- Listen. Bring together those who sell, those who answer customers and those who will update the site. Ask them what customers look for, what they cannot find, and what wastes their time. That is where the real needs lie, far more than on competitors’ sites.
- Decide. Choose the main audience, the expected action and the measure of success. It is the most uncomfortable stage, because it means giving things up — and the one no supplier can do in the business’s place.
- Write. Fill in the five sections, describing needs rather than solutions, and marking what is imposed and what is open.
- Reread as a supplier would. Ask of every sentence whether two people could understand it differently. Each ambiguity found at this stage is a change order avoided later.
The second stage decides the quality of everything else. A well-written specification built on unsettled choices remains a poor specification: it pushes the decisions into the project, where they cost more and are taken worse.
The essential sections of a website specification
Five sections cover the essentials. Each answers a question the supplier will ask anyway; the only difference is whether the answer is written before the quote or improvised during the project.
Context and objectives
Who the business is, what it sells, to whom, and why the project is starting now. Then the objectives, phrased so they can be checked: not “modernise our image” but “get qualified quote requests from the site”, with the indicator that will measure it. Finally, what is out of scope — the section people forget, and the one that prevents the most misunderstandings.
Measurement deserves attention. An objective without an indicator cannot be achieved, only claimed. Number of contact requests, share of visitors viewing a key page, calls avoided on a frequent question: the chosen indicator says what the business really expects from the site, and it will allow the project to be judged six months after launch.
Audiences and journeys
Who must use the site, in what order of priority, and what each comes looking for. A site that addresses everyone convinces nobody: the main audience has to be named, and the others accepted as secondary. For each audience, describe the expected journey, from arrival to action — getting in touch, requesting a quote, downloading a document, buying.
Content and features
An inventory of existing content — what is kept, rewritten or deleted — and above all the answer to a question that often decides the schedule: who will produce the new content? Features, for their part, are described by need rather than by tool: “let a customer book a slot” rather than “install such-and-such module”. Also specify the languages, and the software the site must exchange data with — sales management, invoicing, customer relationship tools.
Technical and SEO constraints
What is imposed and what is open: hosting, content management system, security requirements, handling of personal data collected through forms and cookies, accessibility. For a redesign, existing search rankings deserve a section of their own: which pages bring visitors today, and how they will be preserved — which is the whole point of the steps for keeping search rankings through a redesign. Finally, ownership: who will hold the code, the access rights and the domain name on delivery.
Budget, schedule, selection criteria
Giving a budget envelope does not weaken the negotiation: it lets suppliers propose what can reasonably be done with it, instead of guessing. The schedule sets out the milestones and any fixed date. Finally, the selection criteria say how responses will be decided between — understanding of the need, method, team, references, price — and in what format the response is expected, so it can be read line by line.
Asking for a common response format is the essential complement to this section. If each supplier presents its quote its own way, comparison becomes impossible again. Attach to the specification the list of expected lines — scoping, design, development, content, search optimisation, testing, training, maintenance — and ask for a price for each, with its assumptions and exclusions.
A worked example
Take a fictitious business, for illustration: a firm of chartered land surveyors of around twenty people, whose site is several years old and who find that clients call for information it could publish. Here are some phrasings as they often appear in a specification, and what they become once rewritten.
| Common phrasing | Useful phrasing | Why |
|---|---|---|
| “Redo our site, which is ageing.” | “Our clients call to find out which documents to provide before a boundary survey. We want them to find the answer online.” | The problem is named; the supplier can propose an answer. |
| “The site must be modern and clean.” | “The site is primarily for private landowners, then for notaries.” | A taste cannot be checked; an audience can. |
| “Integrate an appointment-booking module.” | “Let a client request an appointment and attach their documents, without calling.” | The need is described; the tool remains open. |
| “The site must rank well.” | “Current pages that attract visitors must be kept or redirected.” | A checkable requirement replaces a wish. |
Along the way, the firm in the example discovers two things no mock-up would have taught it. First, that its main audience is not the one it imagined: it is private owners who call, not professionals. Second, that the most useful feature is not visible — sending documents without using the phone — and that it requires deciding who at the firm will handle these requests, and how quickly. The specification has done its job before it is even sent.
In each case the useful version is a few words longer and far more demanding. It forces the business to decide what it really wants — which is exactly the work a specification should force.
The mistakes that make a specification fail
- Describing the solution. An imposed site map freezes choices before anyone has discussed them.
- Copying a competitor’s site. It answers that competitor’s problems, not yours.
- Forgetting content. The site is delivered empty, and it is the business that has to fill it, late.
- Withholding the budget. Suppliers guess, and the responses become impossible to compare.
- Declaring everything a priority. What is a priority everywhere is a priority nowhere.
- Setting no acceptance criteria. Without them, delivery counts as acceptance, and disagreements can no longer be settled.
- Writing it alone. A document written without the people who sell and who answer customers misses the real questions.
- Freezing it. Suppliers’ questions often reveal an omission. Better to publish one answer to all of them than to let each correct the document in its own way.
Most of these mistakes share an origin: the specification is written before the business has decided what it expects from the site. That is why so many redesigns change nothing, and why redesign quotes vary so widely. When the web project is part of a broader set of digital investments, an IT master plan sets the framework the specification fits into.
Download the template (PDF)
The template follows the five sections of this article, each with the questions it must answer and space to answer them. It also includes a grid for comparing quotes line by line, and a list of acceptance criteria to set before signing. It is sent by email: nothing appears here — the message you receive is what confirms the address exists.
- the five sections, each with its guiding questions and space for answers;
- a quote comparison grid, line by line, with assumptions and exclusions;
- a list of acceptance criteria to set before signing;
- the mistakes to check for one last time before sending the document.
If you would rather have support with the exercise, this is how Maeliom Build projects begin: the problem first, described and settled, the design second.
Common questions
Who should write a website specification?
The business, because only it knows its problem — but not alone. A useful document involves management, those who sell and those who answer customers, and can be structured with help from someone who will not build the site.
How long should a website specification be?
Long enough to cover the five sections, no more. A document suppliers read in full is worth more than an exhaustive one they skim.
Should the budget go in the specification?
Yes, as an envelope. It lets suppliers propose what is reasonable for that amount, and makes responses comparable.
How does it differ from detailed functional specifications?
The specification describes the need before a supplier is chosen. Detailed specifications describe the chosen solution, and are written afterwards, with that supplier.