Vagueness in a website redesign requirements document should be expensive for the supplier rather than for you. Agencies may call that adversarial, yet “all key pages” can mean 12 templates to you versus 4 to the supplier. Almost every scoping dispute traces to a line that was left unmeasurable on purpose.
If it is vague, it is not vague in your favour. The corollary is blunt: a deliverable without a count, a date and an owner is not a deliverable.
Production sequencing belongs in the 47-step redesign checklist; conversion strategy belongs in our guide to conversion-focused website redesigns. The requirements document records the resulting decisions so that price and acceptance survive handovers.
What a website redesign requirements document must achieve
A useful brief makes two independent estimators reach the same inventory.
Page count alone will not do that. A 24-URL website might require 6 templates, while 6 product pages might require 14 interactive states. The supplier prices templates and states; the buyer often reports URLs. Both numbers belong in the document.
Our Lanteria work involved routing a broad Microsoft 365 HR capability set for several stakeholder audiences. “Create product pages” would not have captured that architecture. The requirement needed to distinguish audience routes, capability groupings and their destination actions.
AfriCap Hub presented a different unit of complexity: its catalogue, filters and registration journey had to work together. Counting the listing page without specifying filter states and registration outcomes would have hidden the functional work.
A requirement should therefore identify the priced unit, the completed state and the evidence used for acceptance. Where a homepage is included, translate specific B2B homepage criteria into named sections and behaviours rather than asking for “a high-converting homepage”.
That distinction also governs our B2B website design and redesign work: approved units are priced and assumptions are exposed.
Measurable scope protects commercial intent.
The eight sections of a website redesign requirements document
Pricing becomes defensible when eight sections survive the same dispute test.
1. Commercial job and boundary
Name the primary action the website must enable, then state explicit exclusions. “Support sales” is not a boundary; “route procurement leads to consultation booking while excluding ecommerce checkout” is.
Dispute test: Two reviewers can independently classify a request as included or excluded from the wording alone.
2. Audiences and journeys
Define four journey fields for every priority audience: entry condition, decision required, destination and accepted completion event.
Lake Erie Shores had two distinct routes under one website: stays and ownership. Combining them as “resort customers” would have concealed different information and actions.
Dispute test: Every scoped journey contains all four fields and one observable completion event.
3. Information architecture and URL inventory
Assign every current and proposed URL one of five dispositions: keep, rewrite, merge, redirect or remove. Record the proposed destination and content owner beside it.
Dispute test: Buyer and supplier produce identical totals for retained, created and redirected URLs.
4. Templates, components and states
Maintain three separate inventories: page templates, reusable components and functional states. A card component with empty, populated and error states is not one effortless object.
Attach homepage requirements to the relevant template rather than treating B2B homepage guidance as an implied supplier obligation.
Dispute test: Every proposed URL maps to a counted template, and every interactive component has named states.
5. Functions, integrations and data
Specify six fields for each integration: system, object, data direction, access owner, failure behaviour and test environment. “Connect HubSpot” says nothing about forms, contacts, consent fields or errors.
AfriCap Hub’s registration journey illustrates why the endpoint matters as much as the interface.
Dispute test: A tester can reproduce all three named outcomes: success, validation failure and downstream failure.
6. Content production and migration
Record six content fields: type, source quantity, source format, producing owner, approving owner and due date. Separate writing, entry and migration because they consume different effort.
Savgen combined industrial valve, turbine and safety tooling across multiple industries. A single line for “technical content” would not distinguish those content populations.
Dispute test: Every content item has a source, treatment, accountable owner and delivery date.
7. Non-functional, measurement and compliance requirements
Name seven boundaries: accessibility target, supported browser versions, hosting ownership, GA4 event schema, Google Tag Manager ownership, Consent Mode behaviour and GDPR/PECR responsibility. “Implement best practice” cannot be accepted or rejected.
Dispute test: Every boundary has either a pass/fail condition or a named decision owner.
8. Deliverables, reviews and acceptance
For every output, provide the count, delivery date and owner. Then define three review controls: included feedback rounds, acceptance window and correction deadline. Two review rounds can be priced; unlimited comments cannot.
Dispute test: A missing, late or rejected output can be classified without inventing another rule.
Eight sections turn interpretation into accountable work.
Three scoping traps and the wording that closes them
The dangerous language sounds reasonable enough to survive procurement.
| Scoping trap | Wording that causes it | Replacement wording |
|---|---|---|
| URLs confused with design units | “Design and build approximately 20 pages, including all key templates.” | “Supplier owns 6 responsive templates and population of 20 named URLs by UAT start; Appendix A is the accepted inventory.” |
| Migration treated as an unlimited verb | “Migrate existing resources as required.” | “Supplier owns migration of 120 published WordPress resources no later than 5 working days before UAT, preserving the five named fields: title, body, author, date and PDF link.” |
| Integrations left open-ended | “Integrate HubSpot and any other tools needed.” | “Supplier owns 2 HubSpot forms and 1 Cal.com embed, with field maps and failure states accepted no later than 10 working days before launch; other integrations are excluded.” |
“Approximately” makes 20 sound finite while leaving the priced unit unresolved. “As required” hides the content inventory. “Any other tools” creates an unbounded technical obligation that the proposal will eventually qualify or charge separately.
Apply three scope triggers before signature:
- If more than 10% of proposed URLs lack an assigned template, halt pricing and complete the map.
- If buyer and supplier content inventories differ by more than 5 items or 10%, whichever is greater, recount them together.
- If the acceptance window is below 10 working days for more than 5 templates, extend the window or reduce the batch.
Impressive-sounding volume claims are not specificity. If a checklist is advertised at 50 items and delivered at 46, the mismatch is a warning about everything else in the proposal.
We claim an uncounted integration scope cannot be a genuine fixed fee; delivery of every subsequently named integration for the original price would prove that claim wrong.
Exact wording is cheaper than post-signature interpretation.
If this analysis exposes wider gaps in your site, we can turn the evidence into a focused redesign brief — book a call
What does not belong in the document
A brief gets weaker when it records taste as an obligation.
1. Visual preferences
“Make it premium” or “use more blue” gives a stakeholder a subjective veto without defining a user outcome. Move brand characteristics into a structured brand personality framework and leave visual responses to the design work.
Visual preferences fail because neither side can prove completion.
2. Technology mandates chosen for familiarity
“Build it in WordPress because marketing knows WordPress” is familiarity disguised as a requirement. A mandate should survive only when tied to a named operational constraint, such as an existing hosting policy or required internal maintenance model.
Familiarity alone fails because it specifies a tool without specifying the problem the tool must solve.
3. Features with no named user
Three speculative features recur in weak briefs. A chatbot without a named audience adds interface and support burden. A calculator without a decision to change becomes a toy. A gated resource library without a follow-up owner creates a form rather than a journey.
Remove any feature lacking a named user, intended action and observable success event.
The honest limit here is that a requirements document cannot prevent genuine change. It can only distinguish a new request from work that should have been included originally.
Taste is not scope.
An illustrative UK B2B scope-cost test
Take an illustrative UK consultancy commissioning a fixed-price redesign. The seven labelled inputs are:
- Base contracted fee: £32,000
- Case studies required by the client: 24
- Case studies allowed by the supplier: 8
- Change price per additional case study: £350
- Page templates required after internal review: 7
- Page templates allowed in the proposal: 4
- Change price per additional template: £900
Five calculations expose the gap:
Content gap cost = (24 required − 8 allowed) × £350 = £5,600
Template gap cost = (7 required − 4 allowed) × £900 = £2,700
Total ambiguity exposure = £5,600 + £2,700 = £8,300
Potential project cost = £32,000 + £8,300 = £40,300
Ambiguity exposure rate = £8,300 ÷ £32,000 × 100 = 25.9%
That is £32,000 quoted versus £40,300 after clarifying two uncounted nouns. It is illustrative scope exposure, not measured client performance or ROI.
What this cannot tell you is whether £350 or £900 is a fair supplier rate. The useful result is the visible quantity gap.
If quantified ambiguity exceeds 10% of the base fee, pause signature and resolve the inventories. Once signed, the requirements become the control surface for website project delivery, not a document forgotten after kickoff.
Unpriced ambiguity is a cost, not a creative freedom.
FAQ
Four procurement decisions deserve fixed answers.
How long should the document be?
Use 6–12 pages for the core terms, then place URL, content and component inventories in appendices. If the core exceeds 12 pages, move evidence rather than deleting acceptance criteria.
Should the requirements document become part of the contract?
Make “attach the signed version as Schedule 1” the procurement decision. If another contract document conflicts, ask your solicitor to state which document takes precedence.
How many people should approve it?
Use 1 accountable approver and no more than 3 named reviewers. Above 3 reviewers, require the accountable approver to consolidate comments before they reach the supplier.
When should a post-signature request become a formal change?
Raise a written change request when the work exceeds 4 supplier hours or alters a signed acceptance criterion. Record the price and date impact before work begins.
Procurement decisions need explicit thresholds.
Summary
Five rules survive the detail:
- Stop pricing when more than 10% of URLs lack an assigned template.
- Price 20 populated URLs separately from 6 designed templates.
- Remove features missing one of three fields: user, action or success event.
- Pause signature when quantified ambiguity exceeds 10% of the base fee.
- Every deliverable requires a count, date and owner before signature.
Actualyse designs and rebuilds B2B websites that turn research visits into qualified pipeline. Book a call to talk through where yours stands.
