A poor website specification document does not show at first. You get three quotes, one twice as high as the others, and when you read the detail you realise each supplier has understood a different site. If you are asking suppliers to quote for a new site or a redesign, this is the document that decides whether your quotes can be compared at all.
My engagements start with a few days of diagnosis, and the specification often comes out of them. Here is the eight-part template I use, how to describe features without writing the technical solution for the supplier, and the checklist I run before sending it. It does not replace a scoping note: it comes straight after one.
01What a specification is for, and what it will not do
The document has two jobs. Before the project, it lets several suppliers quote for the same thing. During the project, it is the reference when a new request arrives: you check whether it is in there, and if not, you decide to add it knowing what that means.
France Num points out that a specification does not need to be a hundred-page technical document: for a micro-business or an SME, five to ten well-structured pages are enough for a brochure site or a simple online shop. I agree, and I would add that long documents are rarely reread.
What it will not do is choose for you between two objectives that pull in opposite directions. If marketing wants a site that generates leads and the board wants one that reassures investors, the specification will simply add the two together. That decision is made earlier, in a two-page scoping note.
02The eight parts of my template
France Num suggests a similar outline: context, objectives, structure and features, third-party tools, evaluation grid, deliverables and timeline, budget. I add journeys and out of scope, because in my view those are the two places where quotes diverge most.
- Context. Who you are, what you sell, to whom, and why the current site no longer does the job. One page at most.
- Objectives, ranked. Three at most, in order, each with a measure. "More demo requests" rather than "modernise our image".
- Audiences and their journeys. For each audience, two or three tasks they must be able to complete on the site.
- Site structure and content. The list of pages, and for each page type: who writes, who signs off, who supplies the images.
- Features, by priority. Must have, nice to have, later.
- The tools the site must work with. CRM, email tool, ERP, booking tool, and for each one the data that moves between them.
- Constraints and out of scope. Legal obligations, languages, hosting, and the list of what the site will not do.
- What you expect from suppliers. Deliverables, timeline, estimated budget, selection criteria, and how acceptance testing will be done.
Part 7 comes from my content machines. The brief for each article has a mandatory field listing what the text must not claim, and the brief is refused while that field is empty. Writing the limits down before starting stops promises slipping in along the way. For a website, "no customer area", "no English version at launch" or "no migration of old articles" cut short weeks of discussion.
The level of detail that is enough
A supplier should be able to quote for the work without calling you about every line. If a feature fits in one word ("blog", "search"), it will be quoted three different ways. If it takes a full page, you have probably started designing in place of the team that will build it. Between the two, three or four lines per feature seem enough to me.
03Describing features without writing the technical solution
You do not need to know which technology the site will run on. France Num says so plainly, adding that it is indispensable, on the other hand, to state which other tools the site will have to work with. That is the right line to draw: you describe the need, the supplier proposes the solution.
To describe the need, I borrow the user story format from the UK government's Service Manual. A story names the user, what they want to do and why. The manual makes a point I find very useful: if you are struggling to write the goal, reconsider why you think you need that feature. Applied to a specification, that question weeds out the features added "because other sites have them".
The same manual suggests writing acceptance criteria as "it's done when…". Here is what that looks like for demo booking. The story: "As a prospect, I want to book a 30-minute demo without swapping emails, so I can pick a slot that suits me." And its criteria, it's done when:
- the prospect sees the free slots of both salespeople;
- the booking creates a contact in the CRM, with the page it came from;
- the prospect and the salesperson both receive a calendar invitation;
- a cancellation frees the slot without anyone stepping in.
Those four lines can be quoted for, and they will be used as they are during acceptance testing. For a journey that changes state on a single page (a checkout, catalogue filters), Nielsen Norman Group describes a useful format: the wireflow, which combines low-fidelity screens with the arrows of the interaction, where a wireframe alone shows poorly what happens after a click. A sketch like that in an appendix is worth a page of text.
04What is almost always missing
Content, first. The specification details page templates and forgets to say who writes the copy, who signs it off and by when. That is then where the timeline slips, and the supplier waits.
Reference data, next. On one project, I saw centimetres and millimetres mixed up between two tools distort an entire product rendering. Nobody had written down which source was authoritative, or in which unit. For a site connected to a catalogue or a CRM, I note for each piece of data the tool that owns it and the one that copies it. I go into more detail on specifying an integration between an ERP and an online shop.
Legal obligations, finally. Service Public Entreprendre points out that a French company website must, among other things, present the business, inform visitors about personal data and cookies, and display terms of sale when selling online. Add accessibility: the European Accessibility Act came into force on 28 June 2025 and covers e-commerce among other services, with micro-businesses exempt. If these points are not in the document, they are not in the quote.
05Before sending: the checklist
In my content machines, a command rereads the brief and answers "refused" with a list of what is missing. I run the same review on a specification before sending it:
- every objective has a measure, and they are ranked;
- every must-have feature has a goal and "it's done when" criteria;
- every page type has someone responsible for its content, and a date;
- every tool connected to the site is named, with the data that moves and the source that is authoritative;
- legal notices, cookies and accessibility are listed;
- the out-of-scope items form an explicit list;
- how replies will be compared is written down;
- the document carries a version number and a date.
The last point looks like admin. On an integration between an ERP and an online shop, the specification changed at almost every meeting. I evolved it version by version, so that everyone was talking about the same document. If you send version 2 to one supplier and version 3 to another, your quotes no longer compare.
06When a specification is not enough
A written document describes poorly what happens on screen. When a journey is at the heart of the project, a clickable prototype before development settles in one session what three rounds of comments on a PDF would not. For the look and feel, showing several mock-up directions at the same level of finish unblocks a decision better than a description of the desired mood.
A specification also freezes the project at the moment you write it. On a product designed from its users, such as the Moonworkers payroll API, needs shift as you learn from them, and a fixed document ages quickly: a priority list kept up to date works better. The format suits a site whose scope can be decided in advance.
Finally, it checks nothing on its own. At delivery, I go back through the "it's done when" criteria one by one, browsing as a visitor who is not logged in, because a site can look fine to the logged-in team and be broken for the public. The acceptance testing and go-live checklist starts from there.
07Where to start this week
Open a document and write parts 2 and 7 first: three ranked objectives and the list of what the site will not do. If you cannot write them, the rest can wait, and that in itself tells you something. Then fill in the journeys, one story per task, with their criteria. The technical side will come from the suppliers' replies.
If several suppliers will have to work together afterwards, keep one version of the document for all of them, as I describe for coordinating multiple suppliers. And if you would like an outside view on yours before sending it, that is the kind of short diagnosis I do in my digital project direction work. Happy to talk it through.