Back to blog

Web design scope document template: 12 sections and a countability audit

Copy a 12-section web design scope document template, apply the number-name-date rule, and score any scope with a 24-point countability audit.

Kristian Hoffmann

SaaS founder and operator

web design scope document template

A web design scope document template is a fixed set of sections you refill for every project: deliverables with counts, explicit exclusions, a defined revision limit, named responsibilities on both sides, a sign-off trigger, and a change procedure. The twelve-section skeleton below covers a fixed-fee website build and pastes cleanly into Word, Google Docs, Notion, or a PDF export.

The template is the easy part. What separates a scope that settles an argument from one that starts a new one is whether each line can be counted. "Responsive design" cannot be counted. "Three breakpoints: 1440 / 768 / 375" can.

The 12-section template

Copy this whole block. Replace the bracketed parts, delete the instruction lines, keep the numbering — the numbers are what you point at in month three.

WEB DESIGN SCOPE DOCUMENT
Project: [name] · Client: [legal entity] · Studio: [legal entity]
Version 1.0 · [date] · Replaces prior verbal and email agreements

1. PROJECT SUMMARY
   Two or three sentences: what is being built, for whom, and what the
   new site has to do that the current one does not.

2. OBJECTIVES
   3-5 objectives in the client's own words, numbered. For each one,
   name the signal both sides will look at after launch.

3. DELIVERABLES
   A numbered inventory. Every line carries a quantity, a format, and
   a destination. e.g. "5 unique page designs (Figma) · 12 reusable
   components · 3 breakpoints: 1440 / 768 / 375"

4. OUT OF SCOPE
   The list that ends arguments. Use the standard ten listed under
   "Exclusions do more work than deliverables" below.

5. TECHNICAL SPECIFICATION
   Platform and version · hosting environment · CMS · integrations by
   name · browser and device support floor · the performance and
   accessibility targets you design to, and who verifies them.

6. CONTENT AND ASSET RESPONSIBILITY
   Who supplies copy, images, logo files, product data — per item,
   with a date. Cross-reference the late-input clause in section 8.

7. TIMELINE AND MILESTONES
   Dates tied to inputs, not to the calendar alone:
   "Wireframes: 5 working days after asset handover is complete."

8. CLIENT DEPENDENCIES AND LATE INPUT
   One named approver, not "the team". Maximum feedback turnaround in
   working days. What shifts when an input arrives late.

9. REVISIONS AND CHANGE PROCEDURE
   Define a round in words. State the number included per deliverable.
   State the rate for further rounds and the written form a change
   request has to take.

10. ACCEPTANCE AND SIGN-OFF
    The event that counts as acceptance: written approval, or silence
    after [N] working days. Name the person who can give it.

11. COMMERCIALS AND PAYMENT SCHEDULE
    Fee · instalments and what each is tied to · expenses · third-party
    costs the client pays directly (licences, fonts, stock, plugins).

12. SIGNATURES
    Name, role, date, both sides. Repeat the version number here.

Whether this document forms part of a binding agreement where you work, and what your revision or termination wording actually means there, is a question for a qualified lawyer in your jurisdiction rather than for a template.

The rule that makes it work: number, name, or date

Every line in a scope document should contain at least one of three things — a number, a named person or role, or a date. A line with none of them is a mood, not a commitment.

Here is the same deliverable written three ways.

LevelHow the line readsWhat happens in week six
Vague"Homepage design"The client expects a mobile version and an animated hero. Neither was priced. Somebody eats the difference.
Countable"Homepage design: 1 desktop and 1 mobile comp, delivered in Figma"Quantity is settled. The argument moves to how many times it can change.
Countable + conditional"Homepage design: 1 desktop (1440) and 1 mobile (375) comp in Figma, 2 revision rounds, further rounds billed at the rate in §9"There is nothing left to interpret. A third round is a purchase decision, not a favour.

Most scope documents in circulation sit at level two. The jump from two to three costs you one clause and removes the conversation nobody enjoys having.

The four clauses that generate most disputes

Deliverable count without a unit

"Five pages" is ambiguous the moment the client counts a landing page variant, a thank-you page, and a 404 as pages. Write the unit: five *unique* page designs, plus a stated number of template variants. Then add the line that saves you later — "additional pages are quoted per page against the inventory in §3."

"Revisions" with no definition of a round

More on the arithmetic below. For now: a round has to be defined as a *thing the client does*, not as a thing you do.

Content responsibility left implicit

Copy is the single most common reason a fixed timeline slips, and it slips silently — the client is not refusing to send it, they are still writing it. Section 6 exists so that the delay has an owner and a date attached before it happens.

Sign-off with no trigger

If nothing in the document says what acceptance looks like, projects end by exhaustion rather than by approval. A silence window is the fix: written approval, or no written objection within a stated number of working days.

Score any scope with the 24-point countability audit

Run this over the document you are about to send, or over one a client sends you. Score each of the twelve clauses: 2 if every element listed is present, 1 if the clause exists but leaves a term undefined, 0 if it is missing or purely descriptive.

§ClauseScores 2 when it contains
1Project summaryThe named site or URL and a stated reason for the project
2Objectives3-5 numbered objectives, written in the client's words
3DeliverablesA quantity and a format on every single line
4Out of scopeAt least eight named exclusions
5Technical specNamed platform version, named integrations, a browser support floor
6Content responsibilityAn owner and a date per asset group
7TimelineMilestones expressed as "N working days after X"
8DependenciesOne named approver plus a maximum feedback turnaround in days
9RevisionsA written definition of "round" and a number per deliverable
10AcceptanceA named event and a silence-equals-acceptance window in days
11CommercialsInstalments tied to milestones, and a payer for third-party costs
12SignaturesBoth names, roles, dates, and the version number repeated

Then read the total:

  • 20-24 — disputes get settled by reading the document.
  • 14-19 — expect one renegotiation mid-project. Write the change-order form now, while everyone is still friendly.
  • 13 or below — this is a proposal summary, not a scope. Do not schedule the kickoff against it.

What an undefined "revision round" costs

Take a five-page marketing site with "two rounds of revisions" and no definition of a round. Substitute your own durations — the structure is the point, not these inputs.

Defined. A round is one consolidated feedback document per page, submitted within five working days. Five pages × two rounds = 10 feedback cycles. At 45 minutes each to read, edit, reply and log, that is 7.5 hours priced into the fee.

Undefined. Feedback arrives as it occurs to people. Four separate messages per page per round is ordinary, not pathological. Five × two × four = 40 touches. Each costs more than a scheduled cycle because you reopen the file cold and re-orient every time — call it 20 minutes. That is 13.3 hours.

A single missing definition is worth roughly 5.8 hours on a five-page site. The sentence that closes it: *"A round means one consolidated set of written feedback per deliverable, submitted within five working days. Separate messages sent after that set counts as the next round."*

If your fee model already assumes a fixed number of cycles, the definition is what makes the fee hold. That relationship between countable scope and predictable price is the whole argument in simple pricing no surprises: how web designers set clear expectations.

Exclusions do more work than deliverables

Section 4 is the part clients read twice and the part most templates leave as a stub. Ten that apply to nearly every website project:

1. Copywriting and content production 2. Stock photography, illustration and font licences — purchased by the client, in the client's name 3. Third-party plugin, theme or SaaS subscription fees 4. Hosting, domain registration and email deliverability configuration 5. Drafting privacy policy, terms or imprint text 6. Data migration beyond a stated record count 7. Accessibility remediation of client-supplied content, and any formal audit 8. Search content production and ongoing optimisation after launch 9. Support for browsers or devices below the floor named in §5 10. Maintenance, updates and bug fixes after the warranty window in §10

Add anything the client mentioned once in a call and you did not price. Those are the items that come back as assumptions.

Word, PDF, Google Docs or spreadsheet

The related searches for this term are mostly about file format, and the honest answer is that format only decides *how* the document fails.

FormatUse it whenThe way it fails
.docx by emailThe client's procurement process expects an editable fileThree versions in circulation by week two, and nobody can say which one was signed
PDFThe document is final and going to signatureEvery amendment needs a re-export and a re-sign, so small changes quietly happen in email instead
Google Docs linkScope is still being negotiated and comment history is worth keepingThe "current" version changes silently — freeze a version-stamped copy at sign-off and link to that
SpreadsheetYou need the deliverable inventory: page counts, component counts, breakpoints, record countsProse clauses — revisions, acceptance, dependencies — do not survive in cells
Structured intake form or portalThe scope fields can be generated from what the client already answeredOnly useful if the form asks scope-shaped questions instead of "tell us about your project"

A practical combination: inventory in a spreadsheet, clauses in a document, one PDF at signature, version number on every page of all three.

Scope document, scope of work, statement of work, brief

These get used interchangeably and it costs people money. A workable separation:

The brief is the client's input — goals, audience, references, constraints, assets. It is written mostly by them. The scope document (or scope of work) is your interpretation of that brief expressed as countable deliverables, exclusions and responsibilities. The statement of work is the same content in contractual register, usually attached to or referenced by a master agreement.

One direction of travel matters here: you cannot write a defensible scope from an incomplete brief. You can only write a guess and then defend it.

The scope document is downstream of the brief

The failure that produces bad scope documents is rarely a missing section. It is a scope written before the client has decided anything — before they know how many pages, whether the logo is final, who signs off, or where the product data lives. You fill the gaps with reasonable assumptions, they read those assumptions as questions still open, and section 3 quietly becomes fiction.

The fix is sequencing, not better wording. Collect the inputs first, in a structured form, so that §3, §5 and §6 of the template are transcription rather than invention. A briefing template for designers gives you the prompts; a web design project template library gives you a version of those prompts per project type, so a webshop intake asks about product counts and a landing page intake does not.

When the brief and the files come back through one link instead of an email chain, the scope document takes minutes to assemble and every line traces to something the client actually wrote.

Redesign and refresh need different lines

A new build and a redesign are not the same template with the word swapped.

Redesign adds a URL map with a redirect count and a migration count. Write the real numbers: "412 legacy URLs — 380 mapped 1:1, 32 redirected to category pages, 0 legacy URLs retired without a target." Also state whether feature parity with the old site is expected, because clients usually assume it is and it is usually the largest hidden deliverable.

Refresh lives or dies on a locked component list. A refresh with an open component list is a redesign, priced as a refresh. Name the components that change and add the line: "components not listed remain as built."

Rebrand plus redesign needs a delivery date for the brand assets in §6. Design work cannot start against an unfinished logo, and "logo delivery" being late is a dependency, not a design problem.

Eight checks before you send it

1. Every deliverable line carries a number. 2. The exclusion list has at least eight items. 3. "Round" is defined in a sentence, not implied. 4. One named approver appears, not a team or a department. 5. Milestones read "N working days after X", not bare calendar dates. 6. Acceptance names both an event and a silence window. 7. Every third-party cost has a named payer. 8. The version number and date appear at the top and again above the signatures.

When a fixed scope is the wrong instrument

Some work does not fit a twelve-section deliverable list, and forcing it produces a document full of guesses that both sides later treat as promises. Discovery-led projects, retained design work, and anything where the deliverable set is the *output* of the first phase belong in a phased structure instead: scope phase one precisely, state that phase one produces the deliverable inventory for phase two, and price phase two afterwards. That is a shorter document and a more honest one.

Analytics consent

We use Google Analytics only after consent to understand reach and product usage.