Website Redesign Deliverables: What to Expect

Website redesign deliverables are the concrete outputs that prove each phase of a project was actually completed.

Knowing what each phase should produce gives you the clarity to evaluate proposals, ask the right questions, and identify when you are receiving less than you paid for.

A redesign engagement without defined deliverables is an engagement without accountability. Every phase from discovery through post-launch produces specific, reviewable outputs. This guide covers them all, phase by phase.

Key Takeaways

• Each Phase Has Defined Outputs: Discovery, UX, design, development, and launch each produce specific reviewable deliverables, not just progress reports.
• Deliverables Are Client Assets: All design files, documentation, and code belong to the client and require formal handover at project close.
• Missing Deliverables Signal Problems: If a phase produces no reviewable output, the work may not have been done or the project was not scoped by phase.
• Post-Launch Deliverables Exist: Redirect maps, analytics configuration, performance reports, and training documentation are deliverables, not optional extras.
• Formal Acceptance Required: Each deliverable should be reviewed and formally accepted, not delivered and assumed approved.

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

How Deliverables Map to the Process

Understanding deliverables within the redesign process requires treating them as phase-specific outputs rather than a flat list. A deliverable list that isn't tied to project phases is impossible to review against a proposal or use to manage project progress.

Why Deliverables Are Phase-Specific

Each phase has a defined purpose, and deliverables are the evidence that the purpose was fulfilled.

• Discovery Purpose: Produce strategic alignment between client and agency through documented research, audience definition, and goal setting.
• Design Purpose: Produce visual solutions that have been reviewed, revised, and formally approved before build begins.
• Development Purpose: Produce a working, tested product that matches the approved design and meets all functional requirements.
• Launch Purpose: Produce a live site with all tracking, redirects, and performance monitoring configured and confirmed.

Each phase's deliverables are the proof that the phase was completed to a defined standard.

Deliverables as Phase Gate Criteria

A phase gate review is the checkpoint between phases that confirms the project is ready to proceed.

• Gate Requirement: Defined deliverables from the completed phase must be produced and accepted before the next phase begins.
• Missing Deliverables: A phase with missing or incomplete deliverables is a gate failure; starting the next phase without resolution creates downstream risk.
• Client Responsibility: Phase gate approval is a client action; reviewing and signing off deliverables is not optional.

Phase gates protect both client and agency from accumulating problems across multiple phases simultaneously.

What "Complete" Means for Each Deliverable

Vague deliverable descriptions create disputes about whether work is done.

• Specificity Standard: Each deliverable in the SOW should have a definition of completion, such as "Sitemap covering all 18 agreed pages, reviewed and signed off by client."
• Format Specification: The format of the deliverable should be specified: Figma file, PDF document, Google Sheet, or staging environment URL.
• Acceptance Criteria: The standard the deliverable must meet before it is accepted should be written into the contract.

A deliverable described only as "sitemap" is incomplete as a contractual specification.

Discovery and UX Deliverables

Deliverables from discovery and UX are the phase most clients receive least rigorously, and the one where shortcomings create the most downstream cost. Discovery deliverables are strategic documents that govern every subsequent design and development decision.

Project Brief and Goals Document

The discovery phase produces a written brief that becomes the contract for all design decisions.

• Audience Profiles: Documented ICP definitions, buying triggers, decision-making patterns, and content preferences.
• Competitive Context: Analyzis of five to eight competitor sites with positioning gaps and design standard benchmarks identified.
• Success Metrics: Specific, measurable goals for traffic, conversion rate, lead volume, and page performance by 90 days post-launch.
• Technical Requirements: Platform constraints, integration requirements, hosting specifications, and security standards documented.

This document should be reviewed and signed off by the client before any design work begins.

Sitemap and Navigation Architecture Document

The sitemap is the structural blueprint for the entire site.

• Page Inventory: All agreed pages listed with their URL paths, parent-child hierarchy, and navigation relationships.
• Content Groupings: How services, products, resources, and supporting content are organized into navigable sections.
• Redirect Implications: Pages being removed, merged, or renamed flagged with their redirect requirements.
• Sign-Off Requirement: The sitemap requires explicit client approval before wireframing begins; changes after approval incur change requests.

A sitemap that doesn't match the final site structure means the design was built without a properly approved blueprint.

Wireframes for Key Page Templates

Wireframes are the functional layouts reviewed and approved before visual design begins.

• Page Templates Covered: Homepage, primary service or product page, secondary content page, blog or resource template, and contact page at minimum.
• Conversion Architecture: Wireframes should show CTA placement, form design, trust signal positioning, and visual hierarchy before color and typography are applied.
• Mobile Wireframes: Separate mobile wireframes for each template, confirming the responsive design logic before build.
• Revision Rounds: The SOW should specify how many wireframe revision rounds are included before change requests apply.

Wireframe approval is the client's opportunity to reshape the site structure without incurring design revision costs.

Design Deliverables

What design and dev deliver at each stage should be specified in the SOW before the project begins. Design deliverables are client assets. They must be formally handed over at project close, not retained by the agency.

Design System Documentation

The design system is the governance document for all visual decisions on the site.

• Typography Scale: Heading sizes, body text, caption, and label styles with defined sizes, weights, and line heights.
• Color System: Primary, secondary, accent, and neutral palette with accessibility contrast ratios confirmed.
• Spacing and Grid: Layout grid specifications, component spacing rules, and breakpoint definitions.
• Component Library: Button styles, form elements, card components, and navigation patterns documented for reuse.

The design system becomes the reference for any future designer or developer who works on the site.

High-Fidelity Mockups by Page Template

High-fidelity mockups are the approved visual reference for the development phase.

• Desktop Mockups: Full-resolution designs for every agreed page template, reflecting the approved design system.
• Mobile Mockups: Responsive versions of every template confirming how components adapt across screen sizes.
• State Variations: Hover states, active states, error states, and empty states for interactive components.
• Approval Requirement: Mockups require explicit written approval before development begins; verbal approval is insufficient.

Any visual element not specified in the approved mockups is out of scope for the development phase.

Design Source Files

Design source files are the client's most valuable post-project asset.

• Figma Files: All design files in the primary design tool, organized by page template and component, with clear naming conventions.
• Export-Ready Assets: Logo files, icon sets, photography, and illustration assets at appropriate resolutions for web use.
• Brand Assets: Typography files, color swatches, and brand element source files as part of the handover package.
• File Organization: Files should be structured so that a new designer unfamiliar with the project can navigate them without guidance.

Source file handover should occur at project close, not held by the agency as leverage for future work.

Deliverables and the Scope of Work

Deliverables and SOW alignment is what separates a professionally structured engagement from a risky open-ended one. The scope of work is the document that makes deliverables contractually binding.

The SOW Deliverables List Is the Contract Basis

A proposal with a comprehensive deliverables list mapped to phases is a professionally scoped engagement.

• Phase Coverage: Every phase from discovery through post-launch should appear in the deliverables list.
• Quantity Specified: The number of pages, templates, or documents to be produced should be written into the SOW, not left open.
• Acceptance Criteria: Each deliverable should have a measurable standard that determines when it is complete and accepted.

A proposal without phase-specific deliverables is a risk, regardless of the agency's reputation.

Line-Item Deliverables Enable Change Management

Itemised deliverables make scope change straightforward and prevent cost disputes.

• Change Request Clarity: When deliverables are itemised, adding or removing one produces a clear cost and timeline impact.
• Scope Creep Prevention: Bundled deliverables make it impossible to identify when a client request constitutes a change versus an agreed deliverable.
• Budget Accountability: Itemised deliverables allow both parties to track budget consumption against agreed outputs at each phase.

How to Evaluate a Deliverables List in a Proposal

Three checks determine whether a proposal's deliverables list is professionally scoped.

• Phase Representation: Check that every phase from discovery through post-launch has at least one defined deliverable.
• Acceptance Criteria: Check that each deliverable has a standard that defines when it is complete rather than just a name.
• Client Responsibilities: Check that the client's obligations, such as content delivery dates, feedback turnaround times, and approval timelines, are explicitly listed.

Missing any of these three elements indicates an incomplete scope that will create problems mid-project.

Development Deliverables

Deliverables in the project plan must include development outputs that clients can verify, not just a URL to a staging environment. Development deliverables are technical outputs that require formal confirmation, not just a "looks good" review.

The Fully Built and Tested Website

The primary development deliverable is a site that meets the approved design and all functional requirements.

• Design Fidelity: Every page template built to match the approved high-fidelity mockups, reviewed against the design in a structured QA process.
• Responsive Testing: Cross-device and cross-browser testing confirmed, with test results documented and shared as a deliverable.
• Integration Confirmation: All CRM, marketing automation, analytics, and third-party integrations confirmed functional before handover.
• Performance Baseline: Core Web Vitals scores measured and documented on the staging environment before launch.

A site that has not been formally tested against the approved design is not a complete development deliverable.

CMS Training and Editorial Documentation

CMS training is a deliverable, not a courtesy.

• Training Session: A structured session covering how to update content, create new pages, publish blog posts, and manage media.
• Written Guide: A documented reference covering all CMS operations, with screenshots and step-by-step instructions.
• Integration Walkthroughs: Training on how to use any integrated tools: form builders, analytics dashboards, and CRM connections.
• Recording: A recorded version of the training session that new team members can access after the agency relationship ends.

Redirect Map and Implementation Confirmation

The redirect map is a technical deliverable that protects SEO equity and prevents broken links post-launch.

• Redirect Document: A complete spreadsheet mapping every changed, removed, or merged URL from old to new destination.
• Implementation Confirmation: Written confirmation that all redirects have been implemented and tested on the staging environment.
• Post-Launch Verification: A follow-up check in the first 72 hours post-launch confirming redirects are working correctly in production.
• Coverage Standard: The redirect map must cover 100% of URLs with existing organic traffic; partial redirect maps are a scope failure.

Launch and Post-Launch Deliverables

The launch phase deliverables list is the phase most commonly omitted from agency proposals and the one with the highest rate of post-project disputes.

Only 30% of redesign clients report receiving all agreed post-launch deliverables. This is the most reliable way to distinguish professional agencies from those that disappear after launch.

Analytics and Tracking Configuration Report

Analytics configuration is a technical deliverable that must be confirmed working before the site goes live.

• GA4 Configuration: Goals, conversion events, and audience segments set up and confirmed firing correctly in the staging environment.
• Search Console Verification: Domain verified, sitemap submitted, and initial crawl status confirmed in Google Search Console.
• Tracking Pixel Confirmation: All marketing pixels, retargeting tags, and third-party tracking scripts confirmed loading and firing.
• Documentation: A written report confirming every tracking configuration, with screenshots as evidence.

Analytics not configured before launch means day-one data is lost and baselines cannot be set.

30-Day Post-Launch Monitoring Report

The 30-day report is a formal deliverable covering the first month of live performance.

• Ranking Changes: Keyword ranking movement relative to pre-launch baselines, with any anomalies identified.
• Traffic Anomalies: Unusual traffic patterns, unexpected drops, or crawl errors identified and explained.
• Crawl Errors: Any 404 errors, redirect chains, or indexing issues identified from Search Console data.
• Recommended Actions: A written list of prioritized actions addressing any issues identified in the monitoring period.

This report is the agency's formal responsibility acknowledgment that they are monitoring the launch impact.

90-Day Performance Review Report

The 90-day report formally closes the project and confirms whether the redesign achieved its stated goals.

• Conversion Rate Comparison: Current conversion rate against pre-redesign baseline, with statistical context.
• Organic Traffic Comparison: Organic sessions compared against the same period in the prior year, adjusted for seasonality.
• Core Web Vitals at 90 Days: Performance scores at 90 days compared against the staging environment baseline and pre-redesign scores.
• Goal Achievement Summary: Assessment of whether each success metric defined in the discovery brief was achieved.

The 90-day report is the final deliverable of the engagement and the document that determines whether the project delivered on its promise.

Conclusion

A complete website redesign engagement produces 15 to 20 distinct deliverables across six phases. All of them belong to the client and all of them should be formally accepted before the project closes.

Missing deliverables from any phase indicate either scope gaps in the original contract or execution failures during the project.

Review any redesign proposal you are currently holding against the deliverables list in this article.

Any phase with no defined deliverables is a phase the agency has not scoped. Address this before signing, not after the project runs into problems.

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 Produces a Complete Deliverable Set, Design Files, Training, and Post-Launch Reports Included

LOW/CODE Agency delivers every deliverable described in this article as standard on every redesign engagement. Design source files are handed over at project close.

CMS training is included. The redirect map is built and tested before launch. The 90-day performance review is delivered to every client.

We are a strategic product team, not a dev shop. Our delivery structure is built around client ownership of every output from day one.

You own the brief, the wireframes, the design files, the code, and the post-launch reports. We do not retain any deliverable as leverage.

• Discovery Documentation: Fully documented project brief, sitemap, and requirements document produced and signed off before design begins.
• Design System Handover: Complete Figma design system including typography scale, color system, component library, and page template files.
• High-Fidelity Mockups: Desktop and mobile mockups for every agreed page template, approved before development begins.
• CMS Training Package: Structured training session, written guide, and recorded walkthrough delivered to the editorial team at project close.
• Redirect Map and Confirmation: Complete 301 redirect map covering all changed URLs, tested on staging and confirmed post-launch.
• Analytics Configuration Report: Full GA4 setup, Search Console verification, and pixel confirmation documented before launch day.
• 90-Day Performance Review: Formal project close report comparing conversion rate, organic traffic, and Core Web Vitals against pre-redesign baselines.

We have delivered over 350 digital products for clients including Coca-Cola, American Express, Sotheby's, Medtronic, Zapier, and Dataiku. See our complete redesign deliverable package to understand exactly what you receive at every stage. Start with a scoping call