A website redesign can begin with a visual problem and quickly become a much larger project. The navigation needs changing, the content is incomplete, the enquiry form behaves differently on phones, and nobody is sure who owns the hosting account. Without a clear brief, these discoveries arrive after design work has already started.
A good redesign brief turns an attractive idea into a project the business can evaluate. It explains what should improve, what needs to be preserved, who makes decisions, and how the finished website will be tested. It also helps a designer propose an appropriate solution instead of guessing what the business means by modern.
This guide is for business owners preparing a redesign, whether the site uses WordPress, Wix Studio, Shopify, Webflow, Squarespace, or a custom platform. The examples are planning scenarios, not claims about completed client projects or guaranteed commercial results.
Define the business problem in observable terms
Start with a short description of the current problem. Instead of the website feels old, describe what happens: visitors cannot find a particular service, the team cannot edit project images, product information is inconsistent, or enquiries arrive without enough context to be useful.
Separate symptoms from proposed solutions. A cluttered homepage may need clearer priorities rather than a new animation. Low enquiry quality may need more accurate service descriptions rather than a larger contact button. Slow content updates may need a better editing process rather than a complete platform change.
Choose a few outcomes the team can assess. Examples include publishing a new portfolio project without developer help, completing an enquiry on a phone, or giving a buyer clear delivery information before checkout. These outcomes support an acceptance test later.
Record constraints early. The business may have a fixed launch window, limited photography, an existing booking integration, or a team member who updates the site once a month. Design choices should respect those conditions instead of assuming unlimited content, time, and operational support.
Identify the audiences and their priority tasks
A website can serve prospects, existing customers, applicants, partners, and staff. Treating all of them as equally important on every page often creates a confusing structure. Decide which audience the main commercial journey should serve first.
For each priority audience, describe the questions they need answered. A facilities manager may need evidence of commercial experience and a site assessment process. A retail customer may need size, availability, delivery, and returns information. An existing client may only need a support route.
Use these tasks to review the current navigation. A heading that makes sense inside the business may be unclear to a new visitor. Ask someone unfamiliar with the company to find a service, a project example, and a contact route. Record where they hesitate rather than defending the current labels.
Write the redesign brief around the tasks that matter most. This gives the designer a reason for the page hierarchy and helps the team assess proposals without relying entirely on personal taste. A visually impressive page is still incomplete if the visitor's main question remains unanswered.
Audit what the existing site already owns
Before replacing anything, list the current pages, articles, products, project records, downloads, forms, and integrations. Include the information that is stored outside the website, such as newsletter audiences, booking accounts, and image libraries.
For each item, decide whether to keep, improve, combine, replace, or retire it. Add an owner who can approve the decision. A page may be outdated but still have useful links, customer bookmarks, or search visibility. Removing it casually can create problems that are not visible in a design presentation.
Review the content against the current business. Old services, former staff, unsupported promises, and discontinued offers should not automatically migrate into the new site. At the same time, accurate project evidence and useful customer explanations deserve attention before someone rewrites them from memory.
Create a separate list of account ownership. Confirm who controls the domain, hosting, CMS, analytics, email delivery, and relevant integrations. The project should not rely on discovering an inaccessible account at the final launch meeting. Our website ownership and handover checklist explains this part in more detail.
Decide the scope page by page
A page list is more useful than an open-ended promise to redesign everything. For each planned page, record its purpose, audience, essential sections, content source, and required functionality. Mark pages that share a template and pages that need a different layout.
For example, a service business may need a homepage, four service pages, an about page, a portfolio listing, project detail pages, an insights section, and a contact page. The project count should distinguish templates from content entries. Designing one project template is different from preparing fifty complete project records.
Specify what happens to articles and older URLs. If content migration is included, explain the number of records, the fields to preserve, who checks formatting, and how images are handled. If rewriting is included, identify which pages require new copy and who supplies factual details.
Include smaller requirements that affect daily use: a readable error state, a proper empty result in search, a footer with accurate links, or the ability to change a portrait from the dashboard. These details are easy to overlook when scope is described only as a list of large pages.
Choose a platform through editing and operational needs
A platform decision should reflect the work the business needs to do after launch. Write down the recurring tasks: adding a project, changing a team image, updating a service, publishing an article, adjusting a product, or checking a form submission.
Ask the supplier to show how those tasks would work in the proposed system. A short editing demonstration can reveal whether the business will need ongoing developer help for routine changes. Also ask who maintains integrations, handles updates where relevant, and manages backups or exports.
Compare limitations honestly. A familiar hosted platform may simplify operations but restrict a specific integration. A more flexible system may require greater maintenance responsibility. Avoid choosing on the basis of one attractive demo feature while ignoring the rest of the website's working life.
If you are comparing operating models, read our cloud CMS and self-hosted CMS guide. The brief should explain why a proposed platform fits the team's actual editing habits and support arrangements.
Write a content plan before visual design
Design is easier to assess when the real content is available. A page built around temporary headings and stock images may look balanced but fail when a longer service explanation, real logo, or unusual project photograph replaces the placeholders.
Prepare a content inventory with the required text, photographs, illustrations, logos, testimonials, and documents. Mark each item as ready, requiring approval, or needing production. Assign a responsible person and a realistic deadline.
Give photography requirements a little detail. A portfolio image may need a wide composition and sufficient resolution for a larger preview. A founder portrait may need safe space around the head so the same asset works on phones and desktop cards. A product image may need a consistent background and multiple views.
Define approvals for factual claims. Results, qualifications, customer names, and testimonials should come from approved evidence. If the team cannot verify a claim, revise it before design locks it into a prominent section. Content accuracy is part of project quality, not a final proofreading task.
Agree the visual direction and motion budget
A visual brief can describe the desired impression without dictating every component. Choose a small set of characteristics such as clear, confident, contemporary, restrained, or editorial. Support them with examples and explain what you like about each example.
Distinguish the design reference from the business requirement. A website with dramatic animation may be appealing, but the relevant lesson could be its hierarchy or use of project imagery. Ask how the proposed motion supports understanding and whether users can reduce or pause it where appropriate.
Specify consistency across the whole site. The portfolio, service pages, articles, forms, buttons, and footer should share a coherent typography and spacing system. Otherwise, the homepage can become a polished exception surrounded by unfinished-looking pages.
Set expectations for smaller screens. Important content should remain readable and reachable without hover. Large imagery should retain its subject, and decorative effects should not compete with the main task. Use the accessible website checklist when reviewing interaction choices.
Protect existing URLs and search signals
A visual redesign does not require changing every URL. Keep useful addresses where possible. When an address must change, decide where the old page belongs and create a clear mapping before launch.
Ask the team to identify important pages using current content records and available search or analytics evidence. Keep titles, descriptions, canonical URLs, internal links, and relevant structured data aligned with the new content. Also check that a staging noindex instruction does not remain on public pages.
Google recommends planning URL mappings, testing the new site, implementing appropriate redirects, and monitoring changes when a site moves. It also notes that rankings can fluctuate while changes are processed. Google's site-move documentation provides the technical reference; it does not promise an immediate ranking improvement from a redesign.
For the detailed launch process, use our redesign SEO migration checklist. Include ownership of that work in the brief rather than assuming it is automatically covered by visual design.
Define acceptance tests before signing off
Acceptance criteria describe observable behaviour. The form accepts valid input, preserves a message when delivery fails, and reaches the correct inbox. A project image can be updated through the dashboard. A product variant displays the expected information. An older URL redirects to the correct new page.
Create a small set of realistic journeys for each important template. Test with real-length text, a longer name, an empty optional field, and actual content records. Test navigation and forms on a phone as well as on a desktop screen.
Include accessibility and performance reviews appropriate to the project. Ask what will be tested, how findings are recorded, and which issues must be fixed before launch. Avoid accepting a score screenshot as the entire quality process; the actual customer journey still needs to work.
Agree who signs off each area. The designer can assess layout, the developer can check behaviour, and the business can confirm operational accuracy. A single vague approval such as looks good should not replace responsibility for content, forms, account access, and launch readiness.
Structure the budget around deliverables and responsibility
A useful quote states what is included, what depends on supplied content, how many review rounds are planned, and how changes are handled. It should explain whether hosting, paid services, subscriptions, image production, migration, training, and maintenance are separate responsibilities.
Do not compare suppliers only by a total price. Compare the work they have committed to deliver. One proposal may include content preparation and migration while another assumes that the business supplies everything in a ready-to-use format.
Identify risks before they become change requests. Missing account access, an undocumented integration, or an unprepared product catalogue can change the effort required. A discovery phase can be valuable when the existing system is difficult to inspect or the business is unsure about its future requirements.
Ask for a clear handover and support arrangement. Specify how defects are reported, what counts as a new request, and who owns maintenance after launch. This keeps the project budget connected to the website's complete working life rather than just its presentation on launch day.
A brief you can use to start a project
Write a short project overview covering the business, audiences, current problems, and desired outcomes. Attach the page inventory, content plan, account ownership list, integration requirements, visual references, and acceptance tests.
Mark what is known and what needs discovery. A brief does not need to pretend every decision is final. It should make uncertainty visible so the supplier can propose a sensible next step and the business can compare recommendations.
Finally, appoint one person to coordinate feedback. Consolidated feedback with reasons is easier to act on than conflicting comments from several channels. Keep a record of approved decisions so later revisions do not repeatedly reopen the same question.
Ali Dev Solutions provides website design and development with practical attention to content, CMS editing, and launch behaviour. Share your current website and priorities to begin with a brief that makes the redesign clear and reviewable.