What Should a Website Redesign Brief Include? From Objectives to Delivery

A website redesign requirements document should turn “why the site is being redesigned, how far the redesign will go, and how the work will be delivered” into actionable agreements. Whether the document is called a website redesign requirements document or a cahier des charges refonte site internet in French, it should enable all parties to use the same material to determine the scope, prepare a quote, schedule the work, and assess the results. When drafting it, first confirm the existing issues and objectives, then specify the pages, features, data migration, and launch responsibilities item by item.

Clarify the objectives and current situation first to avoid simply asking for a “redesign”

Redesign objectives should relate to specific business actions, such as generating more qualified inquiries, supporting multilingual content publishing, or reducing friction when completing forms on mobile devices. For each objective, state the current situation, the desired change, and how it will be measured. For example, an inquiry target can specify that valid leads submitted through forms will be counted, and clearly define how test submissions and spam will be excluded. If reliable historical data is unavailable, agree to establish a baseline after launch and define an observation period rather than inventing a growth percentage.

The current-situation section should document the existing website address, technical architecture, language versions, number of pages, and main issues, and include the existing sitemap, traffic data, and screenshots of representative pages. A decline in page visits and a drop in inquiries may both seem to call for a redesign, but the causes can differ: the former calls for checking indexing and traffic sources, while the latter also requires reviewing forms, product information, and follow-up processes. Separate confirmed issues from items that still need investigation so that the supplier does not treat assumptions as established requirements.

Define the scope: specify pages, content, and features separately

Use a page list to identify pages such as the homepage, product category pages, product detail pages, About Us page, and contact page, and indicate whether each will be retained, redesigned, merged, or removed. For sites with many products, specify which pages will use the same template and which require custom designs. Also list the types and quantities of content expected to be migrated, and identify which party will prepare images and copy. If content is not yet ready, state when it will be provided and how delays will affect the schedule.

Feature requirements should describe the trigger conditions and expected results, rather than simply saying “add an inquiry feature.” For example: after a visitor submits a product inquiry, the system sends a notification to a designated email address, stores the submission in the admin panel, and displays a success or failure message on the page. Required fields, attachment limits, spam handling, and notification recipients should also be confirmed. If a customer management system is involved, list the integration method, field mapping, test environment, and responsibility for maintaining the interface.

For a multilingual redesign, specify each target language, the pages covered, and the source of the translations. Machine translation can be used as a first draft, but product specifications, industry terminology, and contact details need to be checked by a person. Whether product data will be shared across languages and whether content can be edited separately for each language should also be included in the admin permissions requirements. Otherwise, content management may lead to rework after the visual design is complete.

If you plan to use a SaaS website builder, the requirements document should also specify the extent to which templates can be customized, how content can be exported, account permissions, and how data will be handled when the service expires. For example, when evaluating the Yiyingbao SaaS Intelligent Website Building and Marketing System, you can check its multilingual editing, mobile responsiveness, and admin management capabilities against your requirements. The specific scope of delivery is subject to the project agreement.

Include search migration and marketing data in the deliverables

A website redesign often involves URL changes. The requirements document should require a mapping of old URLs to new URLs, define rules for retaining, merging, and removing pages, and specify permanent redirects where appropriate. If an old page has a clear replacement, it should not simply redirect to the homepage. If there is no replacement content, agree separately on how to handle it. Before launch, also check page titles, descriptions, the sitemap, canonical URLs, and search engine crawling settings to prevent restrictions on the test environment from being carried over to the live site.

Existing analytics tools, ad conversion codes, and search platform verification details should also be included in the migration checklist. For events such as successful form submissions and telephone link clicks, specify the trigger conditions and acceptance method, and distinguish test data from live data. If the old site cannot provide complete tracking records, first confirm the administrative access to existing accounts and then schedule a review. The appearance of a page alone cannot show whether conversion tracking is working properly.

Performance requirements should also specify the test conditions: pages to test, device types, network environment, tools used, and acceptable results. Homepage loading speed does not represent the performance of product detail pages or multilingual pages; pages containing many images or videos should be sampled separately. For global access, also agree on the test regions and times. Overall user experience should not be judged based on a single test result.

Tie schedules, changes, and acceptance to specific deliverables

The schedule should be divided into stages with verifiable deliverables, such as requirements confirmation, page design, development and content migration, testing, and launch. For each milestone, specify the deliverables, approver, and feedback deadline. If pages are added or feature logic changes after design approval, document the changes and reassess the schedule and cost to prevent a continual accumulation of informal revisions.

Acceptance criteria should be verifiable through actual use. For example, agree to check page layouts in specified browsers and on mobile devices, submit forms using a test email address and verify the records in the admin panel, and sample migrated pages and redirect results. Record defects according to their impact: issues that block inquiries or make pages inaccessible should be handled separately from display issues such as text spacing, and specify how fixes will be retested. Acceptance should also cover the agreed language versions, rather than checking only the homepage in the primary language.

In addition to the live website, the delivery checklist should include access to the domain and related accounts, admin instructions, page and feature lists, the redirect mapping, test records, and necessary configuration documents. When third-party systems are used, agree on the actual scope of source code or data delivery; do not assume that materials that cannot be provided are included in the deliverables.

Plan the launch with a rollback option

Before launch, confirm DNS settings, certificates, backups, and the release window, and assign responsibility for executing and confirming each step. For backups of the old site, specify the storage location, restoration method, and how availability will be verified. If forms stop working or key pages become inaccessible after launch, agree on the conditions for pausing the release, fixing the issue, or rolling back, as well as the relevant contact details.

Schedule a post-launch observation period to check visits to key pages, inquiry notifications, search engine crawling, and conversion events. Maintenance terms should distinguish fixes for delivery defects from subsequent new requirements, and specify the response channel, handling process, and time limits. After both parties approve the requirements document, retain version records; any subsequent changes should be governed by the updated agreement.