What to Include in a Website Specification Document

A website specification document — often called a "spec" or "functional specification" — is the formal record of what a website will do, how it will behave, and who is responsible for delivering each part. It sits between the brief (what you want) and the design (what it will look like).

For any project beyond a simple brochure site, a well-written spec is essential. It protects both parties, prevents scope creep, and gives developers a clear target to build to. This guide explains what it should contain.

Project Overview and Objectives

The spec should open with a summary of the project: what the website is, who it is for, and what it is intended to achieve. This section grounds every subsequent decision. When a disagreement arises mid-project about whether a feature should be included, returning to the stated objectives helps resolve it quickly.

Include the primary goals of the site (generate enquiries, sell products, provide information), the target user profiles, and any key performance indicators that will be used to measure success after launch.

This section should also state the project timeline, milestone dates, and the stakeholders responsible for decisions on each side. Clear ownership prevents delays caused by unclear approval chains.

Functional Requirements

This is the core of the spec. List every feature and function the site must have, described in terms of what it does and how it behaves. A contact form is not simply "a form" — it should specify which fields are required, what happens after submission (email notification, CRM entry, confirmation message), and any spam protection required.

Cover navigation structure: how many pages, how they are organised, whether there is a mega menu or simple dropdown, and whether there are any pages that are hidden from the main navigation but accessible via URL.

Include user journeys for any complex flows: e-commerce checkout, booking system, user registration and login. Step through each journey from the user’s perspective and specify what happens at each stage.

State any third-party integrations explicitly: payment processors, booking platforms, CRM systems, email marketing tools, live chat software. Each integration has its own complexity and cost — vague references to "connecting with our CRM" lead to disputes about what was included.

Technical and Content Requirements

Specify the platform and hosting environment: WordPress on managed WordPress hosting, a Webflow site with Webflow hosting, a bespoke Laravel application on a VPS. Include any requirements for the CMS — which content types need to be editable, by whom, and to what extent.

List performance and accessibility requirements. Page load time targets, mobile responsiveness requirements, and WCAG accessibility level (typically AA for UK public sector and advisable for all commercial sites) should be stated explicitly.

Include the content supply agreement: which content will be provided by the client, in what format, and by when. State who is responsible for sourcing images, and whether stock photography licences will be purchased by the agency or the client.

Finally, agree on the testing and sign-off process: how bugs will be reported, what constitutes a completed deliverable, and the process for final sign-off before launch. A spec that doesn’t address sign-off leaves room for unlimited revision requests at the end of a project.