Web Design Scope of Work Template (Copy/Paste, With Clear Boundaries)

Web design projects rarely go off the rails because the design is hard.

They go off the rails because the scope silently expands: more pages, more breakpoints, more content, more integrations, more rounds of feedback, and a client who assumes all of it was “part of the website”.

This web design scope of work template is designed to prevent that, and to make the document reusable in Google Docs.

Top pages for this query usually do one of the following:

• offer a generic website SOW template (often via PandaDoc or Smartsheet PDF)
• list phases (discovery, wireframes, design, development, launch)
• include standard items like timeline, responsibilities, and payment terms

What is often missing:

• a clear definition of what “pages” means (templates vs unique designs)
• a boundary around feedback and revisions
• content responsibilities that prevent the project stalling
• explicit exclusions and a usable change request trigger list

RuleDox’s angle is that web design scope is not a single document, it is an assembled output based on variables: CMS, page count, components, content model, and integrations.

Before you list deliverables, decide what kind of website you are actually scoping.

Variables that materially change effort:

• CMS/platform: Webflow vs WordPress vs Shopify vs custom
• Template model: unique designs per page vs reusable templates
• Page count: number of templates, not just URLs
• Responsive requirements: mobile and desktop only, or also tablet and large screens
• Accessibility standard: best-effort vs WCAG target
• Content: who writes copy, sources imagery, and enters content into the CMS
• Migration: number of legacy pages, redirects, forms, downloads
• Integrations: CRM, email, booking, payments, analytics, chat
• Animation and interaction: basic transitions vs complex motion design

If you do not capture these up front, the scope becomes a story after the fact.

Many SOW templates mix everything into a “deliverables” list and hope for the best.

A clearer approach is:

• Design outputs (wireframes, UI, components)
• Build outputs (templates, CMS setup, integrations)
• Content and migration outputs

It makes boundaries obvious. It also makes change requests easier to justify: “this request adds a new template” is cleaner than “this feels like extra work”.

Clients think in pages. Delivery teams ship templates and components.

In the scope, include both:

• a page list (URLs or page names)
• a template list (homepage template, standard page template, landing page template)

Then specify:

• how many unique layouts are included
• which pages reuse those layouts

This prevents the “every page is custom” interpretation.

Most web design scope creep comes from feedback. Not malicious feedback, just endless iteration.

Define:

• number of feedback rounds per phase
• who provides consolidated feedback
• what counts as feedback vs new requirements
• what happens when feedback is late

Example rules you can copy:

• “Feedback must be consolidated by one nominated reviewer.”
• “Additional rounds beyond those included require a change request.”

Templates from proposal tools often include a generic exclusions paragraph. That will not protect you.

For web design, high-signal exclusions include:

• copywriting and photography
• brand strategy and full rebrand (unless included)
• advanced SEO, content strategy, backlink building
• custom integrations not listed
• hosting and ongoing maintenance (unless included)
• complex animations, 3D, custom illustration

Then connect the exclusions to the change process.

Field	Value
Client	[Client name]
Project	[Website redesign / new site]
Version	v[0.1]
Date	[DD Month YYYY]
Prepared by	[Name]

[What the site needs to achieve. Be concrete: lead gen, ecommerce, recruitment, information, brand credibility.]

• Platform/CMS: [Webflow / WordPress / Shopify / Other]
• Page count: [number of pages] using [number] templates
• Breakpoints: [mobile, desktop, plus tablet if included]
• Accessibility target: [best-effort / WCAG 2.1 AA / other]
• Content model: [client-provided / agency-provided / shared]
• Migration: [none / migrate X pages]
• Integrations in scope: [list]

• Kick-off workshop
• Requirements capture and sign-off
• Site map and page list (Appendix A)
• Content inventory (if migration included)

• Wireframes for: [list key templates]
• UI design for: [list key templates]
• Component system covering: typography, buttons, forms, cards, navigation, footer
• Design review sessions: [X]
• Design sign-off (one consolidated approval)

• Build the templates in Appendix B
• Configure CMS collections/types: [posts, case studies, team, etc]
• Configure global styles and reusable components
• Implement forms: [contact, newsletter, enquiry]
• Implement integrations: [analytics, CRM, email]

• Content entry for: [X] pages using client-provided copy and assets
• Migration of: [X] pages/posts from the existing site
• Redirect mapping implementation for: [X] URLs

• QA against acceptance checklist (Section 6)
• UAT support for [X] feedback rounds
• Launch plan including go-live checklist
• Post-launch support window: [X days]

Unless explicitly listed in Deliverables, the following are excluded:

• Copywriting, photography, video production
• Brand strategy or rebrand work beyond applying existing guidelines
• Complex motion design, 3D assets, custom illustration
• Custom integrations not listed in Section 1.2
• Ongoing SEO performance guarantees, content strategy, or backlink work
• Hosting fees and ongoing maintenance (unless included)

Milestone	Target
Kick-off	[date]
Wireframes sign-off	[date]
Design sign-off	[date]
Build complete	[date]
UAT complete	[date]
Launch	[date]

• Deliver the scoped design and build work
• Manage project plan and communication
• QA and defect remediation for scoped work

• Provide access to current site, analytics, and any required accounts
• Provide content and assets by agreed dates
• Provide consolidated feedback within [X] business days
• Approve sign-offs at each milestone

Work is accepted when:

• Templates and pages listed in Appendix A/B are implemented
• Key forms submit successfully and route correctly
• Site is responsive at the agreed breakpoints
• Tracking is installed and receiving events (as defined)
• No critical defects remain open

A change request is required when any of the following occurs:

• Additional templates/pages beyond Appendix A/B
• New integrations, or expanded integration requirements
• Changes to content model (for example, agency asked to write copy)
• Additional feedback rounds beyond those included
• Material changes to accessibility or performance targets

Process:

1. Change described in writing
2. Estimate provided (cost and timeline)
3. Client approval in writing
4. Work begins

• [Home]
• [About]
• [Services]
• [Contact]

• [Homepage template]
• [Standard page template]
• [Landing page template]
• [Blog index + post template]

Detailed enough that another team member could deliver it without interpreting intent. For web design that usually means a template list, component list, feedback rules, and explicit exclusions.

List pages if you have them, but always include the template model. If you only list URLs, a client can interpret every page as a unique design.

Define feedback rounds and require consolidated feedback. When the rounds are used, additional revisions become a change request with clear impact.

Yes. Paste it into a Doc and replace the bracketed fields, then move long lists into appendices so the core scope stays readable.

Instead of copying and editing the same sections repeatedly, RuleDox assembles the scope in Google Docs from your approved modules and the project variables (CMS, page count, migration, integrations). That is how you get consistent scopes even when different people write them.

If you are refining your scoping workflow, pair this with /content/ai/how-to-write-a-scope-of-work, /content/ai/automate-scope-of-work-google-docs, and /content/ai/proposal-tools-vs-scope-assembly.