A good website specification document is your project’s insurance against drift: it aligns everyone on objectives, site structure and scope before the first line of code. Without it, budgets slip and deadlines stretch. Here is a structured template, designed for an SME in French-speaking Switzerland, to fill in before approaching an agency.
Most projects that go off the rails do not go off the rails because of the technology. They go off the rails because nobody wrote down, in black and white, what was expected of the site. Everyone had their own version in their head, and the gaps only appear at delivery, when going back is expensive. The document you hold in your hands before signing is often worth more than the quote itself.
What is a website specification document for
A website specification document serves three concrete purposes, and each one saves you time and money.
First, it frames the project. Putting your objectives, your targets and your constraints in writing forces you to clarify what you really want. It is an exercise in clear-sightedness: many company leaders discover while writing it that their “need for a redesign” actually hides a positioning or content problem, not a design one.
Then it puts quotes on a common basis. Without a reference document, each agency prices what it has understood (or what suits it), and you end up comparing proposals that cannot be compared. With a specification, you compare answers to the same brief: price differences become readable and reveal each supplier’s choices.
Finally, it protects the relationship. If a disagreement arises along the way, the document settles it: what was planned, what was not. It turns a potential dispute into a simple, clearly negotiated amendment.
The essential sections
Photo: Negative Space / Pexels
Here are the blocks that any website specification document should contain. You can take them as they stand and use them as a framework.
Context and objectives
Introduce your company in a few lines: what you do, your market, what sets you apart. Then the essential point: why this project, and why now? A website that no longer converts, an image that no longer reflects the company, a management tool that is impossible to maintain. Then set measurable objectives rather than vague ones. “Having a nice website” is not an objective; “generating qualified quote requests” or “enabling online appointment booking” are. These are what will guide every trade-off that follows.
Targets and site structure
Who visits the site, and to do what? Describe two or three typical profiles and the action you expect from each. This step directly determines the site structure: the list of pages and their hierarchy. A simple diagram (home, services, about, blog, contact) is enough to get started. The aim is not to be exhaustive, but to show how the information is organised and how a visitor navigates to the action that matters to you. It is also a good moment to think about the structure of your content with lasting visibility in mind, a subject we explore further in our article on the topic cluster.
Expected features
List what the site must do, beyond displaying content: contact form, appointment booking, online payment, client area, blog, multilingual, connection to your CRM or your invoicing software. Clearly separate the essential from the desirable. That hierarchy is valuable: it lets the agency propose a solid first version within your budget, then enrich it in stages, rather than wanting everything at once and delaying everything.
Content, languages and identity
Content is the leading cause of delay on web projects, well ahead of technical matters. Be honest: do you have the texts, the photos, the logo? Or do they need to be produced? Specify the languages (in French-speaking Switzerland, French, sometimes German or English for export) because they multiply the writing and structuring workload. State whether you have an existing brand style guide to respect or whether the visual identity is part of the project.
Technical constraints, budget and schedule
Mention your constraints: imposed hosting, tools to keep, compliance requirements (data protection, Swiss legal notices). Give a budget range, even a wide one: it is information, not a weakness. A serious agency uses it to calibrate its proposal where it will be most useful, not to inflate its prices. Finally, set out a realistic schedule with, if you have one, a deadline (trade show, product launch, end of contract with your current host).
The questions to ask before writing
Before you even open the document, answer these trigger questions. They bring the essentials to the surface:
- Who visits my site today, and who would I like to visit it?
- Which single action matters most for my business (call, buy, book, download)?
- What exactly is wrong with what you have now?
- What am I proud of in my company, that ought to come through?
- Who, internally, decides and who approves? (Nothing slows a project down more than an unclear approval chain.)
Common mistakes
Two opposite pitfalls await the website specification document.
The first: a document that is too vague. “I want a modern and effective website” commits no one and allows no serious costing. The vaguer your expectations, the more the quotes will be cautious (therefore expensive) or disappointing.
The second, more subtle: a brief that is too rigid, specifying every technical detail and preventing the agency from advising you. You are paying for expertise: leave it the freedom to propose better than what you had imagined. Describe the what and the why (your objectives, your constraints), leave the how open to discussion.
The right balance: precise on objectives and scope, open on solutions. That is also why a successful redesign is first and foremost a matter of human alignment, as we set out in our dedicated article.
How to use this website specification document with an agency
A specification document is not a dead document filed away after signature. It lives throughout the project, and the way you use it with your provider changes a great deal.
Send it before the first meeting, not during. The agency then arrives prepared, with precise questions and already a first intuition about the solution. You save a whole meeting, and you immediately gauge the quality of their listening: a good partner reformulates your objectives and challenges what deserves challenging, rather than simply ticking boxes.
Then use it as a comparison grid. When several proposals arrive, go through each section and check that everything is covered. An agency that “forgets” multilingual support or the connection to your CRM in its quote has not forgotten by accident: either it did not read it, or it plans to bill you extra for it later. The document brings these grey areas to the surface before signature, not after.
Finally, keep it as a shared reference throughout production. At each validation stage, you go back to the specification: does the mock-up meet the stated objectives? Does the delivered feature match the agreed scope? This simple habit avoids the “this is not what I had in mind” effect at go-live, when corrections cost the most.
A living document, not a formality
Writing a website specification takes a few hours of thought. It is probably the best investment of your whole project: those hours up front save you weeks of misunderstandings, costly back-and-forth and features paid for but never used. A well-framed project is not a rigid project, it is a project where everyone knows where they are going and can focus their energy on what really creates value for your business.
If you remember only one thing: be clear about the why and the what, stay open on the how. The rest is a matter of dialogue with the right partner.
Going further
- Further reading: Website redesign: the challenge is human before it is technical
- To read: Technical debt: why the race for speed can slow you down
A project to scope out? Discover our approach to web design or let’s talk about it.
