When a redesign brief is the right document
A redesign brief is not a general intake form. It exists for a site that already works in some ways and fails in others, and the brief has to describe change, not just desire. If the team is fixing a 40-page corporate website, a landing page, or a product portal, the brief should say what must change and what must stay put.
This matters because redesign work starts with inherited reality. There is already a sitemap, old copy, tracking code, forms, and a CMS with habits baked in. A good brief tells a designer or agency where the pain is, which parts are stable, and which parts are dangerous to touch without a plan.
Think of it as a change-management document. That sounds dry, but it keeps everyone honest. A freelancer can price the work better, an internal team can avoid guessing, and the client side can stop treating every old page like a blank canvas.
If you are looking for how to write a website brief for a redesign project step by step, begin by deciding that the brief is for transformation, not discovery from zero. That one decision changes the questions you ask and the details you collect.
Audit the current site before you write anything
Start with the live site. Not screenshots from last quarter. Not a memory of “the homepage problem.” Open the current pages and list what exists, what is broken, and what nobody should forget during the redesign.
Make a simple audit with numbers. Count the pages that will stay, the pages that will change, and the pages that will be removed. Note any page with strong traffic, any form with drop-offs, any section that confuses users, and any content that is outdated by a year or more.
Technical constraints belong here too. If the current site depends on a legacy CMS, a custom checkout flow, or a fragile integration, the brief should mention it before anyone sketches a new layout. A redesign that ignores the current system often creates a second project: damage control.
Include concrete user issues. For example: support tickets mention search problems on mobile; sales says the pricing page causes repeated calls; the editorial team cannot update FAQs without developer help. Those details are better than broad claims like “the site is hard to use.”
If you already have internal documentation, link it. A team that manages a [website security](https://ostohlo.com/en/blog/bezopasnost-sajta-zashchita.html) review or a tracking setup may already know where the current risks are, and that can save hours later.
Define the redesign boundaries and non-goals
Redesign briefs fail when scope stays fuzzy. Write down what is in scope in plain terms, then write what is not. The second list matters as much as the first, because it stops the team from drifting into extra templates, extra features, and extra approval loops.
Be specific about the boundaries. If the homepage, product pages, and contact flow are included, say so. If the blog archive, language versions, or account area are not part of this phase, say that too. A redesign can touch 12 templates without touching the entire system.
Non-goals are not a sign of laziness. They are protection. If SEO content cleanup is out of scope, say that. If new photography is not included, say that. If the redesign must keep the same checkout provider, write it clearly so nobody proposes a replacement in week 3.
One useful line in a redesign brief is: “Keep the current payment flow intact.” Another is: “Do not change the customer dashboard in this phase.” Simple. Direct. Hard to misread.
Capture the business, brand, and user context
The redesign brief needs context, but not a brand manifesto. Summarize the business reason in one short block: revenue targets, lead quality, support load, recruitment needs, or a new market launch. If the redesign supports a merger, a rebrand, or a shift from B2B to B2B2C, name it.
Brand context should include the parts that changed. Maybe the company is now more enterprise-focused. Maybe the tone moved from playful to expert. Maybe the visual system must feel calmer because the old design looked too promotional. Those are useful details. “Modern” is not.
User context should reflect real shifts, not assumptions. If the audience has become more mobile-heavy, that changes templates and navigation. If returning customers now need account access faster than first-time visitors need education, the homepage, menus, and dashboard should reflect that hierarchy.
One sentence can do a lot here: “The redesign must support three audiences—new leads, existing customers, and partners—without making the homepage carry all the weight.” That gives the team a design problem they can solve, which is better than handing them a slogan.
For a larger project, it may help to point to a related [corporate website](https://ostohlo.com/en/blog/korporativny-sait-struktura.html) structure example or an existing business unit site so the team understands how the organization already presents itself.
Specify page-level needs and site structure
A redesign brief should not stop at “new navigation.” It should name the site structure, the main templates, and the pages that need special attention. Start with a sitemap list, even if it is rough. Then mark the priority pages first.
For example, a 20-page site might need a new homepage, two service templates, a case study layout, a resource hub, and a contact page with a different form. A product company may need a pricing page, a comparison page, and a trial signup flow. A publisher may need archive filters and article templates with stronger reading paths.
Tell the team which page types are repeatable and which are exceptions. If the blog template can handle 500 articles but the case study template needs custom storytelling, write that. If the navigation should surface the top 6 sections only, say so. Numbers help here.
This is also the place for content hierarchy changes. A page may keep the same information but need a different order: proof first, features second, process third, FAQ last. That kind of direction prevents a redesign from becoming a cosmetic swap with the same old structure underneath.
Some teams sketch this against a [website analytics & monitoring platform](https://ostohlo.com/en/work/astrina.html) or an internal content map so they can see which pages already carry the load and which ones are underused.
Note content migration, approvals, and ownership
Content migration is where redesigns get messy. A brief should state what content moves as-is, what gets rewritten, what gets archived, and what must be created from scratch. If there are 86 old articles and only 20 should migrate, say that number clearly.
Ownership matters just as much. Who writes the new copy? Who checks legal language? Who approves the homepage headline? If 4 people approve one page, the schedule will feel it. A brief should name the owner for each step, not just the final sign-off.
Visual approvals need the same care. The marketing lead may approve tone, the product lead may approve feature accuracy, and the founder may want a final look at the top-level message. That is fine, as long as the brief lists the order. Otherwise, the designer ends up revising the same page three times for three different opinions.
Asset ownership is practical. Say who supplies images, icons, diagrams, testimonials, and video. If the redesign depends on 12 product screenshots and they are not ready, that is a schedule risk, not a small detail.
List technical, accessibility, and integration requirements
Technical notes belong in the brief, even if the designer is not coding everything. State the CMS, the hosting situation, the form tools, the analytics setup, and any systems that the redesign must connect to. If the site uses a custom CRM sync or a billing tool, the redesign cannot ignore it.
Accessibility requirements should be concrete. Mention keyboard navigation, color contrast, form labels, focus states, captioning, and screen-reader compatibility where relevant. If the company has a formal standard, cite it. If not, ask the team to follow recognized accessibility guidance and flag any pages that may need extra care.
SEO also belongs here, and not as an afterthought. The brief should ask for redirect handling, preserved metadata where needed, and a plan for pages that are being renamed or removed. One bad redirect map can cost traffic for weeks.
If your team has a custom stack or a private setup, point to it. A redesign for a [private network infrastructure](https://ostohlo.com/en/work/s4m.html) is very different from a public brochure site, and the brief needs to reflect that constraint before design ideas start multiplying.
Testing requirements are worth writing down. State whether the team should test on 3 browsers or 5, whether mobile breakpoints are fixed or flexible, and whether the final handoff needs documented QA notes. Those details save time during launch week.
Add decision criteria and next-step questions for the team
A redesign brief should not end with “please propose ideas.” It should ask the team to answer specific questions. What concept approach fits the current site problem? What risks do they see? What needs more discovery? Which pages should be tackled first, and which can wait?
Ask for estimates in ranges if that is how the team works. Ask for dependencies. Ask which assumptions matter most. A strong brief invites the agency or internal designer to respond with the missing pieces, not just a mood board and a nice PDF.
This section can also define decision criteria. For example: prioritize clarity over visual novelty, or prioritize conversion on the contact page over decoration on the homepage. If the brief says the redesign must not slow page performance by more than a stated limit, the team knows what trade-off matters most. Numbers keep the discussion grounded.
Good next-step questions include: Which templates need prototype testing? Which content areas need a copy workshop? What can be reused from the current design system? Where is the biggest launch risk? These questions help the team move from brief to plan without pretending every unknown is solved.
Some teams also ask for a reference to [choosing a CMS](https://ostohlo.com/en/blog/vybor-cms-wordpress-ili-kastom.html) if platform choice is still open, because platform constraints can change layout, editing flow, and even the scope of the redesign itself.
And if the brief will shape launch support, add one line about what happens after go-live. A redesign that changes URLs, forms, or integrations often needs [website support after launch](https://ostohlo.com/en/blog/podderzhka-sajta-posle-zapuska.html) for a few weeks, not a one-day handoff.
Before sending the brief, read it like the team has never seen the site. If a page count is missing, if a non-goal is vague, if an approval owner is unnamed, fix it now. That is the difference between a redesign brief that drives work and one that just starts a meeting.
