How to brief a redesign — so you do not discover scope in week four

A redesign without a brief costs weeks you see as 'iteration'. The designer draws a home page you like. Week three you discover the booking flow you forgot has to come along. Week four you discover the old URLs are not in the file, and that DNS sits with a previous vendor. You think you have a design problem. You have a brief problem. The pretty Figma is a kind of guess you are paying for.

Teams send the wrong pack. They send mood, because mood is concrete to point at. They forget what must be true after launch, what already ranks, and what is out. So you get a site that looks like the three references — and an old site that is still the truth in Search Console. The concrete thing was the wrong concrete thing.

It is also an SEO and ownership question. If the brief does not say that URLs must live, that you own Search Console, and that the old sitemap must not become a hole, people design a new tree and call 301s 'phase two'. Relaunching without losing rankings is another post. Here the brief just must not make the loss the default because nobody wrote it down.

We write this because 'redesign' has become a purchase you make before you have a sentence about what may change. An honest brief is boring: audience, launch truths, inventory, a death list, how you say yes to a layout, and that the stack may move if the old CMS is why you are sitting here. Without that sentence you have a moodboard. You do not have a redesign you can defend to a board.

A redesign brief is a document that asks one question of the people who will build: can you make these truths hold on a new site, with this that must live, and with this that may die? The answer may be layouts and a stack. The question must not be 'draw something that looks like this'. When the question is already a screenshot, you have not briefed. You have asked for a copy you cannot own.

It is not an RFP. The RFP asks the same question of several parties before you choose. The brief comes when you have chosen — or when the in-house team is about to start — and must be able to point at done without three bids having to sit side by side. If you send a theatre RFP to one agency you have already picked, it is a brief in the wrong clothes. Write it as a brief.

It is not discovery either. A week that produces decisions comes when the brief is thin, or when you do not know whether you need a portal, a shop or a marketing site. The brief is what you already know. Discovery is what you honestly do not. If you put guesses in the brief and call them requirements, you get a site you relaunch again because the guess got stuck in Figma.

And it is not a moodboard. Three sites you like are input for mood. 'Build this site' is how you pay for someone else's information architecture. Let the references say 'this little noise, this clear CTA'. Let the brief say 'a buyer understands the offer in two screen-heights and can send an enquiry without calling'. Mood is allowed. Truths are the duty.

The first failure is that the brief is a look. 'Flatter, more air, our new colour.' Look is a part. It is not the job. A redesign that only changes theme and leaves the information architecture standing is a paint job. A redesign that moves every URL because the new tree 'felt right' is a relaunch you have not briefed as a relaunch. Write whether you are changing look, structure, stack — or all three. Those three are different jobs.

The second failure is hiding what already works. Pages that rank. A form sales actually get leads from. A corner of the site support links to. If it is not in the brief, the designer tidies it away because it did not fit the new grid. Write what must survive with its URL. Write what may die with its URL. Without both lists, 'simplification' is a guess.

The third failure is forgetting operations and ownership. Who publishes after launch. Who owns DNS, Search Console, the cookie setup, the images. If the brief is only about the home page, you get a pretty v1 and an old WordPress you cannot turn off because someone still edits there. Redesign is also an exit from what you are leaving — or an honest sentence that you are staying, and only changing theme.

The fourth failure is mixing RFP, brief and contract. You send 40 pages to one team you have already chosen and call it an RFP. Or you send three sentences on Slack and call it a brief. The document has to make 'done' pointable. The contract comes after. The RFP, if you had one, is already over. A brief that demands a fixed pixel solution on content you have not written is how week four becomes a change order.

A look redesign changes colour, type and components and leaves the URL tree standing. That is honest when you hate the expression and love the structure. It is a trap when you think a new theme will fix that you cannot publish, or that the site is slow for a reason the theme does not own. Write look if it is look. Do not call it a redesign of the business.

A structure redesign moves information architecture, CTAs and which pages exist. That is almost always an SEO job too. If the brief does not mention the URLs that already have impressions, the structure is a new tree you plant on top of an old one. The relaunch post is the procedure. The brief is the permission: what may move, what must 301, what must not be touched.

A stack redesign — WordPress to Next.js, a theme to custom, a hosted shop theme to something you own — is a migration job with a new face. The brief must say why the stack is the problem, not only that you have heard Next.js is fast. Preview deploys, editor flow, a portal beside it: those are reasons. 'We want to look like the sites we sent as a moodboard' is not a stack reason.

Most 'redesigns' are two of the three, without anyone having said which. So the agency draws look, you meant structure, and the stack becomes a change order in week five. Write the three words. Tick them. It is the shortest way to avoid buying a theme when you needed a different URL tree — or a custom site when you needed new tokens on what you already have.