How to Prepare a Website Redesign Brief That Prevents Surprises

A useful redesign brief does not need to prescribe colours, page layouts or a technology stack. It needs to explain the business situation clearly enough that different partners can recommend and quote the same underlying project.

The best briefs reduce assumptions before they become schedule changes. These nine decisions give a designer or developer the context needed to assess fit, risk and effort.

1. Define the business problem

Start with what is not working and why it matters. “We need a modern site” is subjective. “Visitors cannot tell which service fits them, and our team receives the same qualification questions by email” identifies a problem that design, content and workflow changes can address.

2. Name the primary audience and action

Choose the visitor who matters most and the action the site should make easier.

• Who is the primary decision-maker?
• What do they already know when they arrive?
• What concern prevents them from acting?
• Should they enquire, book, buy, apply, donate or visit a location?

3. Inventory the current site

List every page, post, form, download, integration and important external link. Mark what should be retained, rewritten, redirected or removed. This protects useful content and established URLs while exposing the real migration workload.

4. Assign content ownership

Confirm who supplies copy, photography, product data, legal text, translations and approvals. Content delays often look like development delays even when the build is ready. A brief should name an owner and review path for each content type.

5. Document required integrations

Describe the workflow, not only the product name. Include:

• Forms and the mailbox or CRM that receives them
• Bookings, payments, donations or e-commerce operations
• Email marketing, analytics and consent requirements
• Member, staff or client authentication
• Inventory, accounting or other systems that exchange data

6. Decide how the site will be maintained

Identify what your team expects to edit, how often changes happen and who owns updates, backups, security and support. That operating model helps determine whether WordPress, Shopify or a custom application is the appropriate fit.

7. Make accessibility, privacy and SEO requirements explicit

Record accessibility obligations, the personal information collected, retention expectations, existing search traffic and any URLs that must survive the move. These are launch requirements, not polish to add after design approval.

8. Define launch and rollback responsibilities

List the domain, DNS provider, hosting platform and people who control access. Agree on backups, redirects, certificate checks, form testing and the rollback decision before launch day. A safe release should be reversible.

9. Choose evidence for success

Select a small set of observable outcomes: qualified enquiries, completed purchases, applications, booking starts, support demand or content engagement. Record the current baseline when it exists. If there is no baseline, say that measurement setup is part of the project.

Bring these decisions into the first conversation. You will receive more comparable proposals and spend less time correcting assumptions after work begins.