How do you create a growth-driven design strategy for a website redesign?

The method's strategy page puts clear objectives first, so the team knows what result it's building toward before the work starts.

A redesign can have an advantage here that a new site lacks, which is a record. If your analytics and CRM data are usable, they show which pages bring visitors in, where those visitors leave and which form fills turned into customers. The goal can then be stated as a number moving from where it is now to where you need it.

Suppose your site produces 30 demo requests a month and the sales team needs 45. The strategy now has a question it can answer, which is where 15 more requests are most likely to come from. Every idea that comes up later gets judged against that question. Without it, the team has no common measure for choosing between a new animation and a rewritten pricing page.

Analytics show where people leave, and they say little about the reason. The strategy page describes the aim of this stage as understanding the audience's world and the problems the website can solve for them. That takes conversations.

Lean Labs' post on the three stages of growth-driven design describes strategy work that starts with interviews of customers, the sales team and support, because each group sees the purchase from a different point. Sales hears the hesitation before a purchase and support hears the confusion after one, which is worth comparing with what the site promised.

Lean Labs turns those interviews into problem statements. Each one argues for a change in what the buyer does today and names the proof behind it. Those statements set what each page has to say. The post's test of the work is whether sales reads the messaging and recognizes what buyers ask.

We cover one structured way to run this research in how Jobs to Be Done and user research shape a growth-driven design strategy.

The research then gets arranged along the path a buyer takes. The method's page on mapping the buyer's path uses four stages: awareness, consideration, decision and after purchase. For each stage it asks what motivates the visitor, what questions they have, what actions they take and where they get blocked. The answers tell you which pages the site needs and what each one has to settle.

The same page says not every buyer moves through the stages in order. Some skip from awareness to purchase, and others stay in consideration for months. So the map tells you which questions the site must answer, and it can't tell you the order in which a given visitor will ask them. In practice that means each important page has to make sense to someone who lands on it first.

The map also depends on the research behind it. One drawn in a meeting room from opinion alone only records the team's assumptions in a tidier form. Lean Labs keeps its version short, at two to four steps for each core offering, and builds the page structure from it.

By this point you'll have a long list of ideas. The strategy page describes the next move as turning that wishlist into a plan the team can carry out, which means putting the list in order.

A consistent scoring method makes the assumptions behind that order visible. Lean Labs describes using ICE to rank improvements once a site is live: each idea is scored from 1 to 10 on impact, confidence and ease, and the three numbers are multiplied. The same arithmetic works on a strategy wishlist. Suppose the team with the demo request goal scores four of its ideas this way.

The pricing rewrite and the headline rewrite come out on top, and the resource library falls to the bottom. The library might be a fine idea. It scores low because the team judged it a large job and had little evidence that it would produce demo requests.

These scores are the team's judgment written down. They don't forecast a return, and a 336 isn't a promise of anything. Their value is that they make the reasoning visible. When a senior person asks for a new feature halfway through, it gets scored against the goal like every other idea. Rikki Lear's article on how growth-driven design goes wrong makes that point about distractions: with the goals documented up front, ideas that don't serve them sink down the list.

The highest-ranked items shape the first release, which the method calls a launchpad. We describe the format in what a launchpad website is.

The ranking doesn't produce a working site by itself. Some lower-scoring items have to ship because the top ones depend on them. A rewritten pricing page still needs navigation that reaches it, a form that submits and the pages it links to. So the scope of the first release is the top of the list plus the functions and dependencies those items require.

A redesign adds a decision that a new site doesn't face. Your existing pages are already doing work. Some of them bring in search visitors, and some are linked from other sites. The strategy has to say what happens to each group of pages that isn't rebuilt for the first release: keep it, move it as it is, or retire it with a redirect. NP Group's critique of growth-driven design stresses that a redesign means accounting for what was on the old site and preserving its search value. If the plan leaves that out, a small first release puts visitors you already had at risk.

The strategy is also separate from the design direction. Lean Labs' Design Blueprint, for example, sets the look by designing one key page in Figma. That answers how the site will look. The strategy answers what the site says and which pages come first. They're different questions, so finishing one doesn't supply the other. The word blueprint is also used for the strategy documents themselves, which we cover in what a growth-driven design blueprint should include.

A finished strategy is a set of assumptions with reasons attached. You believe the pricing page is losing requests, and you believe buyers care most about a particular problem. The interviews and the existing data have already tested those beliefs to a degree. The launch adds a different check, which is what visitors do on the new pages.

So keep two things from the strategy after the first release goes live. Keep the lower-ranked wishlist, because later interviews and live data can reorder it during the continuous improvement stage. And keep the assumptions in writing, which is the starting point for validating the assumptions behind the strategy. Written expectations give the team something to compare the first results against.