How do you identify and validate the fundamental assumptions behind a growth-driven design strategy?

The method's description of the strategy stage connects three things to an implementation plan: what the audience needs, what the business wants the site to achieve, and a wishlist of ideas. Each connection depends on a belief. The plan says to rebuild the pricing page first because someone believes buyers leave there. The homepage leads with a certain problem because someone believes that problem is why buyers start looking.

A useful test is to ask what you'd build differently if the belief were false, and what it would cost to have built the wrong thing. A belief that decides which pages exist, which offer leads or what the homepage says first carries a large consequence. Rank by that consequence and not by the size of the edit, because a small change on the page where buyers decide can matter more than a large one elsewhere.

You find these beliefs by reading the plan one item at a time and asking what has to be true for that item to be the right work. Several items can rest on the same belief. That raises its consequence, because more of the build depends on it.

"Our buyers care about integrations" is hard to test, because so many different results are consistent with it. Compare a version that names a person, a situation and a consequence: "Operations managers comparing us with a competitor want to confirm we connect to their accounting system before they'll book a demo." Ask operations managers about that belief, and use a page test to evaluate the change it leads to.

A belief backed by a dozen sales calls and a belief that started as one person's opinion look identical in a strategy document. Writing the source beside each one shows which beliefs need research first.

Customers, sales and support can each challenge these beliefs. Lean Labs' article on the three stages recommends talking with all three groups during strategy. In its account, customers can explain why they chose to buy, and sales reps hear the objections and questions prospects raise before signing. Support staff learn where new customers get confused.

The views overlap, and that helps. A belief about what stops a purchase can be put to sales and to customers, and the two answers compared. The same article gives a check to run before design starts. Show the draft messaging to those three groups and see whether they recognize the questions as the ones prospects ask. We go further into that research in how Jobs to Be Done and user research shape a strategy.

The method's page on UX research starts from a question about a difficulty you've seen users have. You then pick a kind of research and interpret what it finds. The page lists interviews, surveys and task-based testing, then heatmaps and session recordings, then analytics such as events and funnels.

The choice follows from what the assumption claims. A belief about motive is best put to people who can describe their own decisions. A belief about behavior calls for watching someone do the task, or for a record of what visitors did. A click on a heatmap shows where someone clicked, and leaves open what they hoped to find there.

Before you choose the variations for a comparison, we'd investigate the cause, because a comparison can only choose among the versions you built. Jen Cardello's article for Nielsen Norman Group illustrates this with a loan application. A team that assumes people quit because the form has too many screens will test shorter forms. If the actual problem is that applicants can't find the interest rate, every variation misses it, and the test reports only which miss did best. Looking into the cause first gives the variations a better chance of addressing the actual problem.

Testing tools handle the mechanics of the comparison. HubSpot's page test, available on Content Hub Professional and Enterprise, serves two versions at the same URL and sends half of the visitors to each. The tool splits the traffic and counts the results. Choosing a variation that addresses the reason people were leaving is the team's job.

Suppose a company sells payroll software to restaurant groups. Its analytics show that most visitors who reach the pricing page leave without requesting a quote. That is the observation, and it's the only part the team knows.

The team's explanation is that buyers leave because the page shows no price. Written so it can be challenged, it reads: "Restaurant operators comparing payroll vendors leave our pricing page because they can't see a starting price." The proposed change is to publish one.

Before building anything, the team looks for evidence that could contradict the explanation. Suppose they interview recent customers and a few prospects who chose a competitor. They also watch several people try to work out from the page what the product would cost them. Suppose the interviews keep returning to a different worry, which is whether setup and tip reporting are included or billed separately. In the task sessions, people scroll past the plan names and say they are looking for what is included.

The observation hasn't changed, but the explanation has. The proposed change is now a section stating what each plan includes, and the starting price moves down the list.

Suppose the page has enough traffic for the team to compare the new version with the current one, and the new version brings more quote requests during the test. That supports the change on this page, for these visitors. It doesn't establish that setup is every buyer's main concern, and the team records the result with that limit. We cover how to frame and run the comparison in how to turn user insights into hypotheses and experiments.

No set number of interviews or visitors settles an assumption. What you can state is what the evidence behind it is able to establish.

A controlled comparison estimates the effect of one change on one counted action, and it says little about motive. Interviews and observed tasks show what people reported and what they did. That suits a belief about reasons, or about where a task breaks down. It doesn't estimate how a change will perform across all of a page's visitors.

So record each belief with the kind of evidence it has, and check that the evidence fits what the belief claims. A winning page test alone leaves a belief about motive unconfirmed.

Some pages won't get a comparison. How long a test needs depends on the page's traffic and on how visitors behave, as Webflow's testing documentation notes. On a page with few visitors, that can be longer than the decision can wait. The team then decides on the interviews and the observed sessions, and labels the belief with the evidence it has.

The list stays open after launch. The method's improvement cycle ends each round by learning from the data and passing the findings to marketing, sales and service. That is the point to update the assumptions. Lean Labs' growth-driven design service shows where new evidence comes from: it draws on page behavior, form and conversion behavior, CRM lifecycle stages and sales feedback. Any of those can contradict a belief that looked sound at launch.

When a belief fails, trace it back to the plan. Look again at the priorities that depended on it before you commit the next cycle's work.