A website redesign often starts with a visual complaint: the site feels dated, the pages look inconsistent, or the brand has moved on. Those are valid observations, but they do not yet explain what the next website needs to accomplish. Use this checklist to turn the conversation into a plan your team can act on.
The key idea
A useful redesign brief connects a business problem, a customer task, and a clear measure of progress.
1. Name the business problem
Write one sentence that explains why the project matters now. Perhaps a new service is difficult to find, visitors repeatedly ask questions the website should answer, or the team needs a developer for every small content change. Each problem suggests a different kind of work.
Replace a broad ambition such as “make the website better” with an observable need: “Help prospective clients understand which service fits their project before they contact us.” This gives design decisions a purpose and makes it easier to evaluate competing ideas.
- What has changed in the business?
- Where does the current website create friction?
- What evidence supports the problem: customer questions, team feedback, or website data?
2. Prioritise the customer’s tasks
A website may serve several audiences, but every page does not need to serve all of them equally. Identify the main visitor groups and the tasks they need to complete. A prospective client may want to compare services; an existing client may need support; a candidate may be looking for a role.
Choose the primary audience for each important page. Then outline a short path: what brings that person here, what they need to understand, and what a sensible next step looks like. This can reveal missing content before any layout is designed.
For example, a consulting service page might need to explain the problem it addresses, the scope of support, relevant evidence, and how an initial conversation works. A large contact button cannot answer those questions on its own.
3. Decide what to keep, change, or create
Make a simple inventory of the current pages. For each one, record its purpose, owner, and proposed action: keep, revise, combine, remove, or replace. Note useful material that is currently outside the website, including sales presentations, customer questions, and approved project descriptions.
Content ownership deserves an explicit decision. Someone needs to supply accurate service information, approve claims, provide images, and confirm whether client work can be shown. A design schedule becomes difficult to maintain when those responsibilities remain implicit.
Also record important page addresses and any content that already attracts useful enquiries. Discuss how those pages will be treated during the transition. Our guide to website SEO foundations covers the structural details to consider alongside the content.
4. Separate launch requirements from later ideas
Divide requirements into three groups: needed for launch, valuable after launch, and still undecided. This makes trade-offs visible. A clear service page may be essential; an elaborate interactive feature may depend on whether the team can maintain it.
List the systems the website needs to connect with and who controls access to them. Booking tools, forms, analytics, and content systems can affect the work even when they occupy very little space in the design.
Agree who makes the final decision and how feedback will be collected. One consolidated response at each review is more actionable than several conflicting requests. Capture these choices in a website brief that everyone can refer back to.
5. Define launch and ongoing ownership
Launch is a handover as well as a technical event. Decide who checks content, who verifies enquiries reach the right destination, and who approves the final release. Include the people who will use the website after the project team steps back.
Choose a small set of signals to review after launch. Depending on the goal, that might be relevant enquiries, completion of a key journey, or the time your team needs to publish an update. Record a starting point when data is available, and avoid treating every change as proof that the redesign caused an improvement.
The final checklist should be short enough to use: a defined problem, prioritised audiences, an owned content plan, agreed scope, and a clear handover. With those decisions in place, visual exploration has something solid to build on.
