SaaS Website Redesign Brief: A Practical Template

A SaaS website redesign brief should explain what your business needs the website to do, who it needs to help, which pages and functions are in scope, and who owns the work. Include the current site, available evidence, content responsibilities, technical constraints, budget assumptions and launch requirements so providers can estimate the same project.

You do not need to arrive with every design decision made. A useful brief makes the decisions you have already made clear and identifies the ones you still need help with.

This guide is for founders and marketing teams preparing to redesign a SaaS marketing website. It includes a page inventory, a responsibility matrix and a template you can copy into your own document. Product application redesigns need a separate workflow and interface scope.

Describe the business and the buying audience

Begin with the product in plain language: what it helps people do, who uses it and who decides to buy it. The daily user and the buyer may need different information from your website.

An operations lead might need to understand how a tool fits an existing workflow. A technical evaluator might need integration details. A budget owner might need to understand the offer and what happens after a demo request.

Name the primary audience for this project and the questions they should be able to answer. Avoid treating “B2B companies” as a complete audience description.

Explain why the redesign is happening

Separate what you have observed from what you suspect.

These are illustrative situations, not research findings or Gestures client results. Your own brief should link to the evidence you have and label assumptions that need investigation.

Define success without inventing a forecast

State the change you want to evaluate and how your team would observe it. For a demo-led website, you might track completed demo requests and assess lead fit using agreed criteria. For a content-led site, you might also examine whether relevant visitors reach product and use-case pages.

Record the current baseline if it is available, including the period measured and the event definition. If it is unavailable, write “baseline not yet established” and assign someone to investigate it. Keep targets separate from promised outcomes.

Inventory pages, content and conversion paths

List the existing URLs before deciding how much of the site needs to change. For each important page, record its purpose, content status and proposed action: keep, update, merge, retire or create.

Count unique page templates separately from the number of URLs. Several use-case pages may share a layout, while a pricing page may need a distinct structure. Both counts help a provider understand the work.

This is an example inventory, not a recommended page count for every SaaS website. Add the actual URLs and content owners in your working version. The blog’s URL count remains unresolved until the existing content has been inventoried.

Once the inventory exists, use a SaaS website structure page map to decide which buyer question each page should answer.

Describe what happens after the CTA

A button label does not define the complete conversion path. Specify the destination and the next step after it.

For a demo request, record the form fields, validation, success message, receiving system and the team responsible for responding. If visitors leave the site for a booking tool, include that handoff in the scope.

Also identify failures that need handling, such as a rejected submission or unavailable booking link. Ask who will implement and check them. This makes the difference between designing a page and delivering its complete action explicit.

Assign content, design and development responsibilities

A website redesign can include several distinct workstreams. A design proposal does not automatically include copywriting, development, CMS setup, migration or ongoing support.

Name who produces each output and who approves it. Where a provider has not yet been selected, use “to be agreed” rather than assuming a responsibility is included.

This matrix is a planning tool. It does not describe what Gestures includes in every engagement. Confirm the actual scope in the proposal and agreement.

Record the constraints that shape the estimate

Constraints make a brief more useful when they explain why a decision matters.

Platform and CMS. State what runs the site today, what must remain and what is open to review. Explain the publishing tasks your team needs to perform instead of specifying a new platform without a reason.

Brand and visual direction. Link to current brand assets and explain which parts are settled. If the visual identity needs work, distinguish that from applying an existing identity to the website. For references, describe the relevant quality, such as clearer product imagery or a quieter typographic hierarchy.

Content and approvals. List copy, screenshots, testimonials and other materials as ready, needing revision or missing. Identify who can approve product claims and permissions to publish customer material.

Accessibility and performance. State applicable requirements and the person responsible for verifying them. Define what is included in design review, implementation checks and testing rather than treating “accessible” or “fast” as a complete acceptance criterion.

Budget and timing. Share the budget range your team can commit if it is known. Explain whether a deadline is fixed and what depends on it. Ask providers to identify dependencies, exclusions and change assumptions alongside their estimate.

For a closer look at what changes an estimate, review the website redesign cost drivers.

Support. Define the questions you need answered after handoff or launch, how long that support is required and who will provide it. Do not assume an open-ended support period.

Include a search and migration section

A redesign can change copy, navigation, templates and URLs. Record what should remain discoverable and who will check the implementation.

If URLs change, prepare a mapping from each old URL to its relevant new destination. Google recommends planning URL mappings, implementing redirects and monitoring the move. Avoid sending unrelated old pages to the homepage. See Google’s guidance on site moves with URL changes.

Your brief should ask for decisions about:

• Existing pages that should remain available and useful.
• URLs that will stay, change, merge or be retired.
• Responsibility for redirects, internal links and canonical URLs.
• Page titles, descriptions, visible headings and relevant structured data.
• Sitemap, robots directives and removal of staging restrictions at launch.
• Who will review Search Console and important user journeys after release.

If your team wants the content to be discoverable in AI search experiences, begin with accessible, useful pages and accurate information. Google states that its established SEO practices apply to AI Overviews and AI Mode, with no additional technical requirements for inclusion. See Google’s guidance on AI features and websites.

Do not put a promise of AI citations, search rankings or traffic into the brief as if it were a controllable delivery item. Specify the work and the checks your team can verify.

Use the redesign brief template

Copy the following template into your working document. Keep unknowns visible and assign an owner to resolve them. Remove sections that do not apply.

1. Business and product

• Company and current website:
• What the product helps people do:
• Primary users and buying audience:
• Main offer and current route to purchase:
• Project decision owner and contact:

2. Reason for the redesign

• What has changed in the business or product:
• Observed website problems and links to evidence:
• Assumptions that need investigation:
• What currently works and should be preserved:

3. Desired outcome and measurement

• Primary outcome to evaluate:
• Primary visitor action:
• Current baseline, period and event definition:
• Target, if agreed; label it as a target:
• Person responsible for measurement:

4. Audience and buying questions

• Primary audience for this release:
• Other evaluators or decision-makers:
• Questions visitors need answered:
• Evidence needed to support product claims:
• Markets, languages and relevant requirements:

5. Page and content inventory

• Existing URL inventory:
• Pages to keep, update, merge, retire or create:
• Unique templates and total URL counts:
• Purpose and primary next step for each important page:
• Copy and assets: ready / revise / create:
• Content producer, approver and expected readiness:

6. Brand and design scope

• Existing brand assets and usage rules:
• What may change and what must remain:
• Visual references and the reasons they are relevant:
• Required responsive layouts and interaction behavior:
• Expected design deliverables and acceptance checks:

7. Build, CMS and integrations

• Current platform, CMS and hosting:
• Required publishing controls:
• Forms, booking tools and receiving systems:
• Submission success and failure behavior:
• Development and integration owner:
• Requirements that need technical investigation:

8. Search, accessibility and migration

• Existing URLs and content to preserve:
• URL mapping and redirect owner, if URLs change:
• Metadata, canonical, sitemap and structured data owner:
• Applicable accessibility requirements and verification owner:
• Performance checks and testing scope:
• Search Console and analytics access owner:

9. Responsibility and delivery

• Content, design, development and launch responsibility matrix:
• Named approver and review process:
• Required editable files and documentation:
• File access, usage rights and third-party licenses to confirm:
• Implementation questions and post-launch support scope:

10. Budget, timing and open decisions

• Available budget range or budget decision process:
• Desired launch date and reason:
• Fixed constraints and flexible preferences:
• Dependencies and decisions needed before estimating:
• Required scope versus a later phase:
• Questions each provider should answer in their proposal:

Worked example: a focused redesign brief

The following example is fictional. It shows how a team could turn a broad redesign request into an estimable starting point. It is not a Gestures project, service commitment or estimate.

Product and audience. A B2B workflow tool helps operations teams manage recurring requests. The website needs to help operations leads understand the workflow and give technical evaluators a clear route to integration information.

Reason for the work. The product has moved beyond the single use case described on the current site. The team has product documentation and recent sales questions to review. It has not yet established a reliable website conversion baseline.

Desired outcome. Make the current offer easier to understand and provide a complete demo-request path. The marketing owner will define qualified requests and establish a baseline before release. No conversion uplift is assumed in the brief.

Initial scope. Review the homepage, product overview, pricing and demo page. Create three use-case pages using one shared template. Inventory the existing blog before deciding whether its listing and article templates need changes. Keep product application UI outside this engagement.

Content. The internal marketing lead will draft copy and collect product screenshots. The product owner will approve capability claims. The design provider should identify content gaps and explain how unfinished copy affects its estimate.

Design and build. The existing identity remains. Request a proposed website structure, visual direction, responsive designs and agreed interaction notes. Internal engineers own development. CMS changes and implementation review must be identified as included or excluded in each proposal.

Search and launch. Preserve existing URLs where they remain suitable. Any proposed URL change needs a mapped destination and a named implementation owner. The release owner will check forms, important links, indexability and measurement before launch.

Commercial questions. Budget approval is pending. Ask for a breakdown by workstream, assumptions about content readiness, required review inputs, exclusions and an optional later phase. Confirm timing after those dependencies have been reviewed.

This brief leaves room for a provider to recommend a different scope. It gives the team a consistent basis for comparing those recommendations.

Review the brief before requesting proposals

Ask a colleague who has not been writing the document to explain the project back to you. Can they identify the primary audience, the required visitor action, the pages involved and the people responsible for getting the work ready?

Before sending it, check that:

• The reason for the redesign is supported by observations or labeled assumptions.
• The page inventory distinguishes URL count from template count.
• Copywriting, design, development, migration and support have named or explicitly unresolved owners.
• The CTA includes a destination and a next step after the click.
• Budget and timing are stated with their dependencies.
• Providers are asked to identify exclusions and respond to the same required scope.

An unresolved decision does not make the brief unusable. Hiding it makes the estimate harder to interpret.

Frequently asked questions

How detailed should a SaaS website redesign brief be?

A useful brief covers five things: audience, desired outcome, page scope, responsibilities and constraints. Keep supporting material in linked inventories or documents. Length is less useful than making assumptions and open decisions clear.

Do we need finished copy before approaching a design studio?

No. You can begin a scope conversation before every page is written. State which copy is ready, who will produce the rest and when it can be approved. Ask how content readiness affects the process and estimate. Do not assume copywriting is included in website design.

Is a website redesign brief the same as a sitemap?

No. The brief explains the business context, audience, scope and delivery responsibilities. A proposed sitemap or page map describes how pages are organized and can form part of that brief. It does not replace content, technical and commercial decisions.

Does a redesign require changing the CMS?

Not by default. Change the CMS only when the current one cannot support the publishing tasks your team needs. Ask the relevant technical owner to assess whether the existing setup can meet those needs and what a migration would involve.

Should a redesign brief include SEO and AI search requirements?

Yes. Include the work that can be checked: preserving useful content, mapping URL changes, maintaining crawlable pages, providing accurate metadata and structured data, and assigning monitoring responsibilities. Record AI search visibility as an objective to observe, rather than a guaranteed result.

Discuss your website scope

A useful starting point is your current website, the audience it needs to serve and the part of the experience that needs attention.

Explore Gestures’ website design services, then bring the scope and open questions you have gathered. We can discuss the work you have in mind and whether Gestures is the right fit.