Websites · 8 min read
The redesign checklist that matters is the one you finish before design starts
Most redesign checklists are launch checklists: redirects, indexing, analytics, the things that go wrong on the day. Those matter and we have a separate tool for them. This is the earlier list — the decisions that, left unmade, are what the launch problems are usually made of.
Written by Zubair Afzal, FounderUpdated
Almost everything that goes wrong in a redesign was decided, or left undecided, before a designer opened a file. The launch is where it becomes visible, not where it happens.
The technical launch checklist matters and it is well covered — redirects, indexing, tracking continuity, the first weeks of monitoring. We keep an interactive one for exactly that, and this page does not repeat it.
What follows is the earlier list. It is less satisfying, because none of it produces anything to look at, and it is where the outcome is actually determined.
The list
Fourteen things to settle before anyone is briefed
If you can answer all of these, you have a brief. If you cannot answer the first three, nothing else on the list will help.
- What the business needs the site to do, in one sentence, agreed by whoever can overrule everyone else
- The three or four actions a visitor should be able to take, in priority order
- Who the site is for, specifically enough to exclude somebody
- A complete inventory of existing pages, with traffic, entrances, enquiries and inbound links against each
- A keep, rewrite, merge or remove decision recorded against every page in that inventory
- A twelve-month performance benchmark exported and stored outside the analytics account
- The named person who writes each new page, and the date they have agreed to deliver it
- The named person who can approve a design without asking anyone else
- What happens to the blog archive, decided explicitly rather than discovered at launch
- Whether the platform is changing, and if so who maintains it afterwards
- The integrations that must survive — forms, CRM, booking, payments, marketing tools — listed by name
- The accessibility standard the build is required to meet, written into the brief rather than assumed
- The performance standard, stated as a field measurement rather than a testing-tool score
- What you own at the end: design files, code, content, hosting accounts, domain and analytics access
Sequence
Five stages, and why this order and not another
The list above is easier to complete if it is worked through in this sequence, because each stage produces the input the next one needs.
Inventory what exists
Every page, with its traffic, entrances, conversions and inbound links beside it. Most businesses discover their site is considerably larger than they thought and that a small number of pages are doing nearly all of the work. You cannot make sensible decisions about what to keep until you know what you have.
You get: A single sheet listing every page with its performance data
Decide what each page is for
Against every row, one of four decisions: keep, rewrite, merge, remove. Recording this now means the architecture is derived from evidence rather than from a diagram somebody drew in a workshop, and it makes the later redirect map a transcription job rather than an investigation.
You get: A keep, rewrite, merge or remove decision for every page
Benchmark before anything changes
Export twelve months of performance data and store it outside the analytics platform. Without this, the question of whether the new site is better than the old one becomes a matter of memory, and memory in that argument is always shaped by who paid for the project.
You get: An exported twelve-month benchmark held outside the analytics account
Write the brief, including the constraints
Objectives, audience, the actions that matter, the architecture derived from step two, the integrations that must survive, the accessibility standard, the performance standard, and who approves what. This is what makes three quotes comparable, and it is what prevents a review process becoming a competition between opinions.
You get: A written brief that another agency could quote against without asking you anything
Agree the terms while somebody still wants the work
Ownership of code, design files and content. Who holds the domain, hosting and analytics accounts. What documentation is handed over. What happens if the project stops halfway. These are cheap to agree before a contract is signed and expensive to negotiate afterwards.
You get: Ownership, handover and exit terms written into the contract
Do not postpone these
Four decisions that get deferred and should not be
Each of these is comfortable to leave until later and expensive to leave until later. They are the ones we would ask about first.
Who writes the content
Not "we will sort content out as we go". A named person per page, with a date. Content is the most common cause of a redesign overrunning, and it is the one part a design supplier cannot produce without knowledge that only exists inside your business.
Who has final approval
One named person who can approve a design without consulting anyone else. Review processes without a decider become taste competitions, and the taste that wins is the most senior person in the last meeting rather than the one closest to the customer.
What happens to the archive
Years of blog posts, old service pages, case studies, news items. Some earn traffic and links, most do not. Deciding page by page is work; deciding by accident at launch is worse work, done under time pressure, by whoever is available.
Who maintains it afterwards
If the platform is changing, this decides which platform is appropriate. A codebase handed to a business with no developer becomes a site nobody can change, and the consequence shows up eighteen months later rather than at launch.
Commercial terms
What belongs in the contract, and what we refuse to sign
Insist on these
- Ownership of the design files, the code and the content on completion, stated explicitly rather than implied.
- Domain, hosting, analytics and search console accounts registered to your business, not to the supplier.
- A full page inventory and redirect map inside the scope, priced rather than assumed.
- A defined support period after launch, with what it covers written down.
- Handover documentation good enough that a different supplier could take over without a discovery project.
Treat these as warnings
- A quote with no content plan in it. The content will still have to be produced, and the cost has simply been moved to you.
- A fixed price with no page count or scope definition, which resolves into a change-request conversation later.
- Hosting that can only be provided by the agency who built it, with no export path stated.
- A launch date agreed before the content deadlines are agreed. One of those two dates is fictional.
Questions
What people ask before commissioning a redesign
How much of this can the agency do for us?
Most of it, and two things they cannot. They cannot decide what your business is trying to achieve, and they cannot supply the subject knowledge inside your team’s heads. Everything else — inventory, architecture, benchmarking — can be delegated, and is usually cheaper if you do the first pass yourself.
The reason to prepare rather than delegate entirely is that it makes quotes comparable. Three agencies working from three different interpretations of a vague brief will return three prices that cannot be compared to each other.
What is the most common reason a redesign runs late?
Content. Design can proceed on placeholders for a while and then stops, and the material has to come from people inside the business who have other jobs. Deciding who writes what, and by when, before design starts is the single most effective schedule protection available.
The second most common is a review process with no agreed criteria, where each round produces new opinions from new people and nothing ever gets signed off.
Do we need to keep all our old pages?
No, but every decision to remove one should be deliberate and recorded. Pages that bring in traffic, links or enquiries should survive in some form. Pages that do nothing can go, and removing them is often an improvement rather than a loss.
What causes damage is not deletion but silent deletion — pages disappearing because nobody noticed they existed, which is exactly what an inventory prevents.
How long should we benchmark before starting?
Long enough to cover your seasonality, which for most businesses means the previous twelve months rather than the previous month. Export it and keep it somewhere outside the analytics account so a later platform change cannot take it away.
The point is not the SEO ritual. It is that six months after launch, when somebody says the new site is performing worse, there is a record that settles the question instead of two people remembering differently.
Should the content be written before or during design?
Before, at least in draft, for the pages that matter most. Designing around real content produces layouts that fit what you actually have to say; designing around placeholder text produces layouts that your content then has to be squeezed into.
It also surfaces the awkward discovery early — that nobody in the business can currently explain what you do in three sentences — while there is still time to solve it properly.
Want somebody to check the brief before you send it out?
Send us the brief you are about to give to three agencies. We will tell you what is missing, what will cause a change request later, and which parts will produce quotes you cannot compare.
Last updated