What to prepare before a website redesign

Know what the site is for

"It looks dated" is a reason to start; it is not a goal. A website has a job: generate qualified enquiries, close hiring candidates, support a sales conversation, sell a product. Pick the primary one and write it down, because every design decision downstream is an argument that gets settled by that sentence.

A useful test: finish this line before you brief anyone. "Twelve months after launch, this redesign will have worked if ___." If the blank contains a number, even a rough one, the project has a spine.

Bring the content, or a plan for it

The single most common cause of a stalled web project is not design and not development. It is content that was "coming next week" for three months.

You do not need finished copy on day one. You need to know:

• What pages exist and why. A one-line purpose per page beats a sitemap of forty empty boxes.
• Who is writing. You, the studio, a copywriter? Decide before the schedule is built, not after it slips.
• What already works. If one service page produces most of your enquiries, that page's content is load-bearing. Say so.

Design built around real content survives contact with reality. Design built around lorem ipsum gets rebuilt.

Know what is working today

Redesigns are dangerous to the things nobody is watching. Before anything is thrown away, pull the numbers: which pages people actually land on, which ones convert, what visitors search for, which links get clicked in your emails. Ten minutes in your analytics can save a top-performing page from being casually deleted because it was ugly.

If you do not have analytics worth reading, that is useful information too, and worth fixing as part of the project.

Collect examples, then say why

Every client brings reference sites, and they are genuinely useful, with one amendment: the value is not in the link, it is in the sentence after it. "We like this" tells a studio almost nothing. "We like how fast you understand what they sell" is a design requirement.

Three or four references with reasons beat thirty without. Include one site you dislike, with reasons; it is often more revealing.

Decide who can say yes

The most expensive sentence in a web project is "let me show this to a few more people." Feedback from many people is healthy; decisions from many people are fatal, because a website that five stakeholders all approve of is usually the average of five websites.

Before kickoff, name one person who can approve work. Everyone else advises. Projects with this rule finish; projects without it get a second kickoff in month four.

What you do not need

You do not need a finished sitemap, wireframes, a brand book, or a technical specification. Producing those is what a studio is for, and arriving with them pre-decided mostly means paying professionals to reverse-engineer your own assumptions. Bring the goal, the content plan, the evidence, and the decision-maker. That is a complete brief.

If you have those four things, or want help getting them, we should talk.