Ask five agencies for their redesign process and you'll get five versions of the same diagram: discovery, design, development, launch. All of them true, none of them mentioning where redesigns actually die. The dangerous phase isn't wireframes or migration. It's the one before the diagram starts, where somebody decides what the site is for, who it must persuade, and what it has to say. Most processes give that phase a paragraph. On a B2B site, where six stakeholders and an eleven-touch buying journey hang off every page, it deserves half the calendar. This is the full sequence with honest timeboxes, and a dated project record showing what the order buys.
Key takeaways
- The sequence is Decisions, then Design, then Build. Every failed redesign I've seen ran the same phases in a different order, usually by letting decisions leak into design reviews.
- "Decided" means written down and closed. A decision that lives in someone's head reopens in every review. A decision on paper is something a build team can execute.
- The decisions phase is weeks, not months. It's the cheapest phase of the project and the only one that determines whether the expensive phases run once or three times.
Why most redesign processes start one phase late
The standard process starts with discovery: stakeholder interviews, analytics, a competitive scan. Useful work. But look at what it produces in most projects: a findings deck, not a set of closed decisions. The project then rolls into design carrying open questions like unsigned checks. What is this site's one job? Who is it for first? What's the message? Nobody answered, so the design phase answers by default, one revision round at a time.
That's why the visible symptoms of a broken redesign are always design-phase symptoms: endless review cycles, stakeholders relitigating direction on mockups, messaging rewritten in parallel with development. The disease sits a phase earlier. The process didn't start late; it started in the middle.
The full sequence with honest timeboxes
The website redesign strategy that works has three phases, and the timeboxes below are ranges I'd actually defend, not sales-deck optimism.
Decisions, typically two to four weeks. Positioning for the current stage, priority audience, core message, site structure, and page priorities, settled with the people who own them and written down. Ends with a brief the build can execute.
Design, typically four to eight weeks. Wireframes against the agreed structure, visual design against the agreed message. Reviews check execution against decisions instead of reopening them, which is what keeps this phase inside its box.
Build, typically four to eight weeks. Development, content migration, QA, launch. On a B2B site the technical risk concentrates here: preserve your URL equity or redirect it deliberately, following Google's own documentation on site moves rather than a plugin's defaults.
Totals land between ten and twenty weeks for a mid-market B2B site. Teams quoted twelve weeks who deliver in thirty didn't get slower engineering. They ran the decisions phase inside the design phase, at design-phase prices.
The decisions phase, step by step
This is the half of the process nobody documents, so here it is in working order.
What gets decided, and in what order
Four decisions, sequenced so each feeds the next: what the site is for (its one job for this stage of the business), who it must persuade (an audience ranked first, not a list), what it must say (the message, written in sentences, not adjectives), and what gets built (a structure that follows from the first three). The full logic of those four sits in what is website strategy; the redesign process is where they get closed on a deadline.
Who has to be in the room
The people who own the answers, which is smaller and more senior than the project team: whoever owns positioning (usually CEO plus marketing lead), whoever owns revenue (sales sees the objections the site must pre-empt), and the single person with authority to close a question and keep it closed. Vendors and internal teams execute decisions; they can't source them. A room without the owners produces recommendations, and recommendations reopen.
What a closed decision looks like on paper
A one-line answer, an owner, and a date. "The site's job is to generate qualified demos from compliance leads. Decided by MK, June 3, revisit after Q1." Sounds bureaucratic; takes thirty seconds; survives every design review that follows. If a decision can't be written this way, it wasn't made, it was discussed. The full set becomes the brief: structure mapped page by page, each page with a stated job, priorities ranked, exclusions explicit. Producing that brief with the decision owners is the engagement I run as a Website Strategy Consultant, and it's the deliverable the next two phases execute.
A week-by-week shape that works
The decisions phase compresses well when it's run as a schedule instead of a conversation. Week one is diagnosis: read the analytics, interview the owners separately (separately matters, it's how you find the disagreements), and put the current site's implicit strategy on paper, because the old site was answering the four questions somehow. Week two puts options on the table: two or three ranked positioning directions with a recommendation, and the audience call made explicitly. Week three turns the chosen direction into words and structure: the message written in full sentences, the sitemap drafted page by page with a job attached to each. Week four closes: the owners walk the brief end to end, objections get argued now instead of in design reviews, and the document ships with names and dates on its decisions.
Four weeks is the comfortable version; I've run the shape in two with a decisive team. What it can't survive is being made asynchronous. Review-by-email stretches every close into a fortnight, because silence reads as consent right up until the design review where it turns out it wasn't. Written down, those four weeks double as a redesign checklist: when a week's output is missing, you know exactly which arguments you postponed.
Design and build, running on rails
When design starts from closed decisions, the phase changes character. The first wireframe review argues about wireframes, not about who the company is. Copy arrives before layout, the content-first order, instead of being poured into it. And revision rounds collapse, because the feedback "this doesn't feel right" gets tested against a written message instead of against six private opinions.
The handoffs between phases are physical, which is half their value. Design receives the brief: message, structure, page jobs, priorities. Build receives approved layouts plus the same brief, so when implementation questions come up (they always do), the answer lives in a document instead of a meeting. Anything that changes mid-phase gets written back into the brief, or it resurfaces as a surprise in QA.
I can show this on the record. Fiscallion, a fractional CFO firm, ran exactly this sequence in 2025: strategy and website architecture opened the project on 26 May and closed on 18 June, ahead of wireframes, design and development on the same project board. The build executed against settled decisions, and the site went from one ranking keyword to 260 within fourteen months, becoming a cited source in AI answers along the way. The dated board is the part I'd show a skeptic: the phase order isn't a philosophy, it's a schedule you can read.
The failure modes that stretch redesigns
- Rolling discovery. The strategy phase has no end date, so it quietly continues inside design, billed at design rates. Fix: decisions get a deadline and an owner before design is scheduled.
- Decisions by revision. Round three of homepage feedback is actually a positioning argument wearing a design costume. Fix: when feedback contradicts the written brief, route it to the decision owner, not the designer.
- The late stakeholder. A senior voice joins at 80% built and reopens everything. Fix: the owners' room in the decisions phase exists precisely so this person argues early, on paper, when changes cost nothing.
- Migration as an afterthought. The new site launches and organic traffic halves because nobody mapped the old URLs. Fix: treat URL mapping as a build-phase deliverable with its own review.
Final thoughts
The uncomfortable math of redesigns: the decisions phase is the cheapest few weeks of the whole project, and it determines whether the expensive phases run once or several times. Teams skip it because it doesn't produce anything visible, and visible progress feels like progress. But nobody frames the findings deck. What ends up on the site is whatever got decided, somewhere, by someone. The only question is whether that happens on purpose, at the start, or by exhaustion, in review round seven.
FAQ
How long does a B2B website redesign take?
Ten to twenty weeks end to end for most mid-market B2B sites: two to four for decisions, four to eight for design, four to eight for build. The spread isn't about site size as much as decision readiness. A team that enters design with closed positioning ships near the bottom of the range; a team that argues direction on mockups can double the calendar without adding a page.
Do we need this if we already have brand guidelines?
Guidelines answer how things look and sound; a redesign runs on decisions about what the site is for, who it serves first, and what each page must prove. Most brand books are silent on all three. If yours genuinely answers them, the decisions phase becomes a fast confirmation exercise. Usually it surfaces that the guidelines describe the company from two funding rounds ago.
Should we restructure the site or just redesign it?
Check where the friction lives. If visitors find pages easily but don't convert, the problem may be message and design. If qualified visitors can't locate what they need, or the navigation mirrors your org chart instead of their questions, structure comes first, and a visual redesign on top of a wrong structure is polish on a maze. Structure decisions belong in the decisions phase either way.
When is a redesign the wrong move?
When the current site's problem is a decision problem wearing a design costume. If leadership can't agree what the company sells or to whom, a redesign will execute the disagreement in higher fidelity. Close the direction first; sometimes the result is that the current site needs three pages changed, not a rebuild, and that discovery costs a fraction of the project it replaces.
How do we keep our SEO traffic through the redesign?
Treat every URL with traffic or links as an asset with a forwarding address. Crawl the current site, rank pages by organic entrances and referring links, and map each one to its successor with a 301 before launch day. Watch Search Console for the following month: some reshuffling is normal, cliffs are not. The mapping is a build-phase deliverable with its own review, not a launch-week afterthought, and it's the difference between a redesign and a restart.
