Website Redesign Requirements: What to Capture

Documenting website redesign requirements before writing a brief is the difference between a quote that matches your project and one that does not.

A brief without a requirements document produces an estimate that bears no reliable relationship to the actual project scope, and a project that bears no reliable relationship to the actual budget.

According to project management research, requirements gaps are responsible for up to 47% of project failures. Every requirement discovered after scope is signed adds cost, time, and friction to the project.

Capturing requirements upfront is cheaper, faster, and produces a better brief, a more accurate quote, and fewer surprises once the project is underway.

Key Takeaways

• Requirements precede scope: Scope cannot be defined accurately until requirements are documented. Scope is the agency's translation of requirements into deliverables.
• Missing requirements are expensive: Every requirement discovered post-sign-off adds cost, disrupts the timeline, and typically costs more than if included from the start.
• Requirements have four categories: Functional, technical, content, and strategic requirements are distinct and each needs dedicated attention.
• Stakeholder input is a requirements source: Sales, support, and marketing teams hold requirements knowledge that the brief rarely captures without deliberate effort.
• Requirements must be prioritized: Not all requirements carry equal weight. A priority ranking resolves scope trade-offs when budget forces choices.

Webflow Development Services

Webflow Experts On-Demand

Whether you're starting fresh or need a full revamp—we create fast, modern Webflow sites built for growth.

Let's talk

Requirements in the Planning Context

Where requirements fit in planning is one of the first things to clarify. Requirements are not a section of the brief, they are the foundation the brief is built on.

Requirements Come Before the Brief, Not After

The requirements document is the input to the creative brief and the scope of work. Writing a brief without documented requirements produces a vague brief and a guessed scope.

• Sequence: Requirements document first, creative brief second, scope of work third. Reversing this sequence creates a brief that may not reflect what the project actually needs.
• Brief quality: A brief built from documented requirements is specific, testable, and provides the agency with enough information to produce an accurate quote.
• Scope accuracy: The scope of work is only as accurate as the requirements it translates. Incomplete requirements produce an incomplete scope.
• Discovery value: Even in projects where the agency conducts a formal discovery phase, the initial requirements document sets the starting point that discovery refines.

Requirements Are the Client's Responsibility

While the agency helps refine and validate requirements during discovery, the initial requirements document is the client's input.

• Internal knowledge: The client holds knowledge of their audience, competitors, internal systems, and business goals that no agency can replicate without extensive research.
• Stakeholder input: The requirements document should capture input from all internal stakeholders, not just the project lead's assumptions about what the project needs.
• Early investment: The time invested in building a complete requirements document before briefing an agency is returned many times over in a more accurate quote and a smoother project.
• Responsibility for gaps: Requirements discovered after scope sign-off are typically the client's financial responsibility as scope additions. Incomplete upfront documentation is a self-inflicted cost.

Incomplete Requirements Cost More Than Complete Ones

Every requirement discovered mid-project requires a scope change assessment, disrupts the timeline, and typically costs more to implement than if it had been included from the start.

• Change order cost: A feature added mid-project requires a change order with an impact assessment, agency time that is billed before a line of development is written.
• Timeline disruption: Mid-project scope additions push back the timeline for every phase that follows, not just the phase currently underway.
• Design rework risk: A functional requirement discovered during build may require a wireframe and design revision before it can be implemented.
• Compound effect: Multiple small requirements discovered across the project compound into significant cost and timeline overruns.

Strategic Requirements

Strategic factors behind requirements include the business-level decisions that determine what the redesign must achieve, not just what it must include.

Business Goals and Success Metrics

Document the specific outcomes the redesign must produce and the current baselines against which they will be measured.

• Lead generation targets: If the current site generates 50 qualified leads per month and the redesign goal is 80, that target must be in the requirements document, not assumed.
• Conversion rate targets: Specify the current conversion rate and the target. This requirement constrains the UX and conversion architecture decisions the agency makes.
• Traffic goals: Organic traffic growth targets are requirements that affect the SEO and content architecture scope of the project.
• Baseline data: Current baselines for every metric, traffic, leads, conversion rate, rankings, must be documented so post-launch evaluation has a meaningful comparison point.

Target Audience Requirements

For each primary audience segment, document what the site must communicate, enable them to do, and prove to build trust.

• Primary audience definition: Who visits the site, what brings them there, and what they need to find or do before they convert.
• Content requirements per segment: Different audience segments may need different content, a B2B buyer needs case studies and credentials; a technical evaluator needs specifications and documentation.
• Trust signal requirements: What certifications, client logos, testimonials, or credentials does each audience segment need to see before they trust the business enough to convert?
• Journey requirements: What is the primary conversion path for each audience segment, and what content must exist at each step to keep them moving forward?

Competitive Differentiation Requirements

What must the site do or communicate that competitor sites do not?

• Competitive analyzis basis: Review three to five competitor sites before writing differentiation requirements. Requirements based on competitive reality are more actionable than those based on aspiration.
• Content differentiation: Specify the content topics, formats, or depths that will differentiate the site from competitors, not just "better design."
• UX differentiation: Identify specific UX improvements that competitors have not achieved, faster product findability, simpler booking processes, better mobile experience.
• Positioning differentiation: Articulate the brand positioning claim the site must reinforce and the proof points that support it, requirements that constrain every content and design decision.

Functional Requirements

Functional requirements define what the site must be able to do. These are the requirements most commonly missing from briefs, and the ones that produce the most expensive mid-project surprises.

Content Types and CMS Requirements

List every content type the site must support and specify the CMS editing capability required for each.

• Content type inventory: Blog posts, case studies, team profiles, product pages, service pages, resource downloads, event listings, testimonials, list every content type explicitly.
• CMS editing requirements: For each content type, specify what editing capability is required: rich text, custom fields, media library, revision history, scheduling, multilingual support.
• Editor roles: Specify who will edit the CMS and what their technical comfort level is. A non-technical editor requires a simpler CMS interface than a developer-managed content process.
• Publishing workflow: If content requires approval before publishing, document the approval workflow as a CMS requirement, not all platforms support complex editorial workflows without custom configuration.

Forms, Conversion Tools, and Interactive Elements

Document every form, calculator, booking tool, and interactive feature the site must include.

• Form inventory: Contact form, quote request form, demo booking form, newsletter subscription, downloadable resource gating, list every form by type and purpose.
• Data capture requirements: For each form, specify every field required, which are mandatory, and where the data goes, CRM, email marketing platform, internal notification.
• Interactive elements: Product configurators, pricing calculators, assessment tools, live chat widgets, each requires explicit scoping.
• Integration requirements: Every form and tool that needs to connect to a third-party system must name that system and specify the integration type required.

Search, Filtering, and Navigation Features

For sites with large content libraries, document the search and filtering requirements explicitly. Requirements that define scope at this level of specificity are what make the difference between an accurate estimate and a significant undercount.

• Site search: Does the site require site search? If so, what should search return, pages, products, blog posts, documentation, and what is the expected index size?
• Filtering requirements: For product pages, resource libraries, or case study collections, specify every filter dimension required, category, industry, product type, format, date.
• Navigation architecture: Specify the navigation structure required, single-level, dropdown, mega-menu, and whether there are specific navigation features required for specific audience segments.
• Pagination and load-more: Specify how large content collections should paginate, traditional page links, infinite scroll, or load-more buttons, as these have SEO and development implications.

Technical Requirements

Technical requirements are where most briefs have the largest gaps, and where the most expensive scope surprises originate.

Platform and Integration Requirements

Specify the platform preference and every mandatory integration before briefing an agency.

• Platform preference: If there is a mandatory platform, WordPress, Webflow, Drupal, Contentful, state it. If the platform is open to recommendation, state what constraints apply.
• Mandatory integrations: CRM system name, email marketing platform, analytics tools, ad pixels, customer support tools, and any other systems that must connect to the website.
• Systems that cannot be replaced: If there are existing systems that the new site must connect to, an internal ERP, a legacy ordering system, a proprietary CRM, these are hard technical requirements.
• API availability: For each integration, document whether the third-party system provides a standard API, requires a custom integration, or has known limitations that affect what data can be exchanged.

Performance and Security Requirements

Document minimum performance targets and security requirements before the brief is issued.

• Lighthouse targets: Specify minimum acceptable Lighthouse scores for performance, a target of 85+ on mobile performance is a professional standard that constrains technology and asset choices.
• Core Web Vitals: Specify LCP, CLS, and INP targets if these are relevant to the business context, e-commerce sites, high-traffic content sites, and enterprise sites should have explicit CWV requirements.
• Security requirements: SSL certificate, data encryption standards, login security protocols, and any specific data protection compliance requirements (GDPR, HIPAA, SOC 2) relevant to the business.
• Hosting requirements: Specify any hosting constraints, preferred hosting provider, geographic region for data storage, uptime SLA requirements, or existing hosting contract commitments.

Accessibility and Compliance Requirements

Specify the required accessibility standard and any legal compliance requirements applicable to the business.

• Accessibility standard: WCAG 2.1 AA is the professional baseline for business websites and the legal standard in many jurisdictions. Specify this as a requirement, not an aspiration.
• Regulatory compliance: Healthcare, financial services, and government organizations may have additional compliance requirements, ADA, Section 508, HIPAA, that constrain platform and feature choices.
• Cookie and privacy compliance: GDPR, CCPA, and local privacy law compliance requirements should be documented, they affect cookie consent implementation, data handling, and analytics configuration.
• Legal content requirements: Terms of service, privacy policy, and cookie policy pages are legal compliance requirements, not optional content sections.

The requirements-to-scope translation is documented in our requirements feeding the SOW guide, useful reading before briefing an agency with your completed requirements document.

Content Requirements

Content requirements are the category most frequently underestimated in project briefs, leading to scope additions that are entirely avoidable.

Page Inventory and Migration Requirements

List all current pages and specify migration decisions for each.

• Full page inventory: Export every URL from the current site using a crawl tool. This list is the starting point for the migration decision for each page.
• Migration decisions: For each page or page type: keep as-is, rewrite, merge with another page, redirect to a new URL, or delete. These decisions are scope inputs.
• Content rewrite scope: If pages require rewriting, specify the scope, who writes the copy, what the word count target is, and what the review and approval process is.
• Content ownership: Assign a content owner for every page type, the person responsible for supplying or approving the copy before the build phase begins.

New Content to Be Created

Specify all pages and content types that need to be created from scratch.

• New page types: New service pages, landing pages for paid campaigns, case studies, industry pages, or any content that does not exist on the current site.
• Word count guidance: Specify a word count range for each new content type, service pages at 800 to 1,200 words, case studies at 600 to 900 words. Unspecified word counts produce inconsistent content.
• Content brief requirement: Specify whether the agency or the client is responsible for content briefs for new pages. Content without a brief produces generic copy that fails the SEO and conversion goals.
• Content timeline: New content that needs to be created before the build phase starts must have a production timeline that begins well before build.

Brand Asset and Media Requirements

Document what brand assets exist, what needs updating, and what needs to be created. For guidance on turning these content requirements into a creative brief, see turning requirements into a brief.

• Existing brand assets: List available assets, logo (all file formats), brand guide, color codes, typography files, existing photography, and video.
• Assets requiring update: Outdated logo versions, old brand colors, low-resolution images from legacy campaigns, each requires a production decision in the requirements document.
• New assets to create: New product photography, team headshots, illustration sets, icon libraries, or brand videos that the redesign requires but that do not currently exist.
• Photography brief: If new photography is required, specify the style, subjects, and usage contexts in the requirements document, these decisions affect both cost and timeline.

Documenting Requirements Formally

Worksheet for capturing requirements is the practical companion to this guide. The format of the requirements document matters almost as much as its completeness.

Structure the Document by Category

Organize requirements by category, strategic, functional, technical, content, and design constraints, so the agency can address each systematically during scoping.

• Section headers: Use the four categories, strategic, functional, technical, content, as primary sections. Design constraints and brand requirements can form a fifth section.
• Consistent format per requirement: Each requirement should have: a description of what is needed, the business reason it is needed, and the priority level assigned to it.
• Numbering: Number each requirement so that references during agency briefing, discovery, and scoping are unambiguous.
• Change log: If the requirements document is updated after initial issue, maintain a change log so the agency can identify what has changed between versions.

Assign a Priority Level to Each Requirement

Mark each requirement as must-have, should-have, or nice-to-have.

• Must-have: In scope regardless of budget. These requirements define the minimum viable project and cannot be deferred.
• Should-have: In scope if budget allows. These requirements add significant value but could be deferred to a second phase without defeating the project's primary objectives.
• Nice-to-have: Future consideration. These requirements are documented so they are not forgotten, but they are not expected in the initial scope.
• Budget forcing function: When an estimate exceeds the budget, the priority classifications determine which requirements are removed from scope and which are non-negotiable.

Get Sign-Off From All Stakeholders Before Issuing

A requirements document that has not been approved by all stakeholders will be revised after the brief is issued.

• Internal review process: Circulate the requirements document to all relevant stakeholders, marketing, sales, IT, legal, leadership, before issuing it to the agency.
• Consolidation session: Run an internal workshop to review the requirements document together. Disagreements resolved internally are free; disagreements discovered post-brief issue cost agency time and delay the project.
• Formal sign-off: The requirements document should be signed off by the project sponsor before it is shared with any agency. This gives the document authority.
• Agency issue date: The date the requirements document is issued to the agency starts the clock on the brief response timeline. Issue it when it is final, not when it is a draft.

Conclusion

A complete requirements document is the single most valuable preparation investment before a redesign. It produces an accurate scope, a reliable quote, and a project that actually matches the budget.

The time spent building it is returned immediately in the form of a better brief, a more precise estimate, and far fewer mid-project surprises.

Start with the four categories, strategic, functional, technical, content, and list at least three requirements per category.

The gaps that surface in that exercise are your next research tasks before the document is complete enough to share with an agency.

Webflow Development Services

Webflow Experts On-Demand

Whether you're starting fresh or need a full revamp—we create fast, modern Webflow sites built for growth.

Let's talk

LOW/CODE Agency Helps You Capture the Right Requirements Before Scoping

LOW/CODE Agency includes a requirements workshop as part of the discovery process on every engagement.

We help you identify what you need before we scope what we are building, so the scope is based on documented requirements, not assumptions.

We operate as a strategic product team, not a dev shop.

Our discovery process surfaces requirements you did not know to document, validates the ones you did, and produces a scope that reflects the actual project.

• Requirements workshop: Structured discovery workshop with your key stakeholders to surface and document requirements across all four categories before any scoping begins.
• Stakeholder interviews: Interviews with sales, marketing, customer-facing, and technical teams to capture requirements knowledge that the project lead alone cannot provide.
• Technical requirements review: Technical audit of your existing platform, integrations, and systems to document constraints and integration requirements accurately.
• Content audit: Current page inventory with migration decision recommendations, keep, rewrite, merge, redirect, or delete, as an input to content scope and timeline.
• Requirements prioritization: Priority classification for every requirement, must-have, should-have, nice-to-have, so scope trade-offs are governed by business value, not budget pressure.
• Brief development: Translation of the documented requirements into a structured creative brief that gives our design and development teams a clear mandate.
• Scope validation: Every scope item traced back to a requirement, so you know exactly why each line item is in scope and what business objective it serves.

LOW/CODE Agency has delivered 450+ digital products for clients including Coca-Cola, American Express, Sotheby's, Medtronic, Zapier, and Dataiku. We are a redesign agency for complete scoping that starts with requirements, not assumptions. Start with a scoping call