You sit between the client and the developer. The client already promised a new-looking site before the campaign. You have a date and a folder of layouts. The developer still needs one answer: what is part of this redesign, and what is not. In week one, that answer often comes from whoever speaks first. That is not creative work. That is missing scope.
The word redesign hides three different purchases. A new look. New copy. New behaviour, such as a request that finally reaches the place where the team works. The client often paid for the first one. The campaign often needs the second and third as well. The developer can build any of them, and will guess the rest if the brief says nothing. Later, that guess becomes the thing the client says they never approved. Then launch week turns into rework week.
1. Write what this redesign is for, before you attach files
Start with one sentence the client would sign. Not a slogan. A change in what a person can do, or in where your campaign sends traffic. “A person who clicks the spring ad lands on a page that names the offer, the city, and a request the sales team sees the same day.” If you need three sentences, you may be buying three projects. Pick one for this invoice, or split the invoices before kickoff.
Then write why the current site fails that sentence. “Slow” is not a reason until you name the page and the seconds. “Ugly” is not a reason until you name the page the ad will open. “The brand feels old” is a feeling. It does not tell a developer which template must stay untouched. Put the failure into words a non-designer can verify. The longer note on timing, before anyone redraws the brand, is what to check before a redesign.
Name the campaign date and the build date as two separate dates. They are not the same. If ads start on Monday, the page those ads open must be acceptable on Friday, on a copy of the site, not on the live site at midnight. One date called “launch” is how week one fills with panic. Say which date belongs to the media plan, and which date belongs to the developer.
2. Split look, copy, and behaviour into three lists
Look is what a person sees: type, colour, photography, block order. Copy is the text you are ready to publish. Behaviour is what happens after a tap: where the request goes, what a returning customer can still do, which address must keep working because search and ads already point there. A redesign brief with only the first list will still be judged by the third.
Put each item on one list, and mark which list this invoice includes. If copy is not ready, say the build is waiting for copy. Do not ask the developer to invent headlines and then debate them in review. Placeholder text often becomes final text. If behaviour is “same as now,” say that, and name the flows that must keep working. “Same as now” without a list is how checkout disappears during a visual pass.
Visual files still matter. They are not the whole brief. If two files exist, say which one wins, and put a date on it. A designer’s constraints, the states a layout must include, and what you should hand over with the file are covered in what to give a developer with the layout. Attach that. Do not replace it with a longer chat about taste.
3. Name the pages in, and the pages this week will not touch
A redesign that starts with “the whole site” has no real week one. It has a tour. List the addresses that change in this phase. List the addresses that stay as they are, including the blog, the login, old campaign URLs, and any page a current ad still uses. People skip the “will not touch” list because it sounds negative. It is the line that stops a rebuild.
If the campaign needs one new landing page, that page can be the whole phase. The rest of the site can wait. Clients hear “redesign” and picture every template. You can reject that picture in one line, before the developer opens the repository. A homepage refresh that also rewrites the catalog, the account area, and the mail templates is four projects. Bill four projects, or cut three before Monday.
Keep the addresses that already rank or already receive ad traffic. A new look that changes the path is a migration. Say who owns the domain and the host, and how the developer gets access without a password dropped into a group chat. The general attachment list is in what to attach before development starts. This note adds the extra boundary around the word redesign.
4. Freeze a week-one scope a tired person can repeat
Week one needs a smaller promise than the whole redesign. Put it on one page: the outcome sentence, the pages in scope, three to seven checks that mean “this slice is acceptable,” and the name of the one person who can decide when the client and the brand disagree. Not a committee. One name, and how fast that person answers. A developer who waits three days will guess on day two, because the media date is still on the calendar. On Friday, that guess gets called a mistake.
The checks are clicks, not feelings. Open the ad URL. Read the offer and the city without scrolling on a phone. Send one request. Confirm thank you appeared on the site and that the same request is in the place sales already opens. Change one sentence the client said they must control. Confirm a page you marked out of scope still looks like last week. “It feels premium” is not a check. Save that for a later list.
Also write what week one will not include, even if someone already mentioned it in a meeting. A second language. A new chat. A full catalog import. A checkout rewrite. Those lines let you answer “while you are in there” without a fight. The owner-side version of this pack is what to give a developer so the build is not redone. If you already have that pack, add the redesign boundary to it. Do not write a second document that disagrees with the first.
5. Name the risks that make the date a lie
Three risks show up in the first week of a redesign more often than a bad font. There is no copy of the site, so every attempt happens on the live one. Nobody knows where a request must appear. The current platform cannot do the behaviour the new layouts assume, and nobody has said that out loud.
If the only place to try a change is the live site, say that before you promise Monday. A visual tweak on the live site is how a campaign page breaks on Saturday. Creating a separate place to test the work is part of the job, not a delay. The reason is in why you should not patch the live site because a test environment is missing. Put that place in the brief as a requirement.
If the layouts show a booking widget, a new checkout, or a form the sales team has never used, ask where the result must land before you approve the layouts. Thank you appeared on the site is not the same event as a person on the team seeing the request. Walk one example. If the platform cannot send it there, the redesign is a behaviour project, and the date you gave the client was only for a new look. Fix that sentence this week, not after the ads start.
6. Review the slice you froze, then add the next slice
When the first slice is ready, walk the checks you wrote. Do it on the copy of the site, with the client if you can, using the same list. Do not start with taste. Taste will find the headline and miss the request path. Park visual notes that sit outside the list. They belong in the next slice, not as a reason to call this one unfinished when the checks pass.
If a check fails, name the line. “It feels off” is not a line the next build can satisfy. If the client adds a page during review, write it as a new line with a new date, or refuse it. Adding it silently is how week one becomes week three with the same invoice. Your job in that meeting is to protect the boundary, not to collect every idea saved since last year.
Keep the brief in one place the next person can open. A chat is not that place. When you are away, the developer and the client should still see the outcome, the boundary, and the checks. Redesigns get rebuilt when that note lived in one head. Add a few lines every time the scope changes. Do not start a new document that contradicts the old one.
When to bring a developer in before you promise the date
You can draft this boundary yourself if you know the campaign and the current pages. Bring a developer in before you promise the date when the layouts assume behaviour the current site may not have, when nobody can point to a copy of the site that is safe to break, or when the client has already described the redesign as “everything, but quickly.”
Services include reading a redesign brief like this and naming what is still three projects, so the extra work does not come back as a second invoice in week two. Selected work shows results next to the operation, not as a gallery of moods. If you write, send the one-sentence outcome, the pages you believe are in week one, and where a test request should appear. Leave passwords and customer records out of the message.