How can AI improve growth-driven design research, testing, and optimization?

Growth-driven design improves a live site in repeating sprints. The method's description of that cycle has four steps. You plan around one focus metric and build the changes you ranked highest. Then you learn from the experiments and the data, and pass what you learned to marketing, sales and service.

AI can take on parts of those steps, and it leaves their order alone. It can summarize research for the planning step and draft copy or page versions for the build. A test in the learning step still waits on visitors, because it measures what people do on the page and they arrive at their own pace.

So the useful thing to ask about any AI tool is what it's working from. A tool that reads your customers' own words is organizing evidence you collected. A tool that writes a customer's words for you is proposing something you still have to check.

The first place to use AI is on the customer material you've already collected, such as recorded sales calls, support tickets and interview transcripts. The job there is turning the material into themes someone can act on.

Dovetail's overview of its AI features shows what this looks like inside one research product. It turns recorded calls into transcripts. When you add transcripts or PDFs to a project, it writes a summary of the main points. It also marks notable moments in interviews and usability tests, and it sorts them under the tags you already use.

Dovetail also says the answers its chat gives are traced back to the source material, so an analyst can go from an answer to the transcript behind it and read the quotes. The product marks the content AI generated and shows when a person has edited or approved it.

We'd make reading the quotes a rule before any theme goes into a sprint plan. If a theme says buyers are confused by pricing, the quotes should show buyers saying so. When they don't, you've caught the error before it turned into a page. Once a theme holds up against its quotes, you can turn it into a hypothesis and an experiment.

Some tools go a step further and simulate the customer. You describe a buyer, and the model answers interview questions as that buyer. The output reads like research, which is why it deserves a careful look.

Nielsen Norman Group tested this in 2024. Its researchers used two AI tools to simulate interviews for three studies they had already run with real people, then compared the answers. In a study of online courses, real learners said they often didn't finish a course. The synthetic users said they had finished every one.

The authors concluded that synthetic users suit desk research and generating hypotheses, and that they shouldn't replace research with real people. Their evaluation covered particular tools at a particular time, so it isn't a verdict on every model released since. The reasoning carries over, though. Growth-driven design exists to replace assumptions with observed behavior, so a simulated interview belongs with the assumptions.

It still has a job there. You can use a simulated interview to draft a discussion guide, or to list the objections a buyer might raise. Treat each one as something to investigate with real buyers.

A model can draft many versions of a headline or a page section on request. The number of people who visit the page doesn't grow to match, and that limits what a test can do with the extra versions.

HubSpot's page A/B test shows the mechanism. On Content Hub Professional and Enterprise, you publish two versions of a page at the same URL, and half the visitors see each one. HubSpot recommends changing one variable at a time so you can see cause and effect. You then choose the winner, and the other version goes back to draft.

HubSpot reports how each version performed and leaves that choice to you. Judging whether the difference is real is your job, and it depends on how many people have seen each version.

Suppose your pricing page gets the same number of visitors every month, and nothing else about the page or its traffic changes. You test two headlines with an equal random split, so each headline gets half the visitors. Now suppose your platform allows more than two versions and you test ten headlines instead, again with an equal random split. Each headline gets a tenth of the visitors. At the end of the same month, every comparison rests on a fifth as many visitors per version as before.

So AI can widen the set of ideas, and someone still has to narrow it to the versions worth the traffic. We'd start that narrowing from what the research said buyers were stuck on.

Some platforms apply AI to the traffic split itself. Webflow's documentation on creating a test describes two kinds. A traditional test gives each variation a fixed share of randomly allocated traffic and looks for a single winner. An AI-optimized test shifts traffic toward whichever variation is performing best for each type of visitor, and it keeps adjusting as behavior changes.

A fixed test is designed to compare versions on equal terms. When it produces a clear winner, the finding applies to that page, that audience and that period. A fixed test can also end without a clear winner.

An adaptive test is designed to send more traffic to whatever is doing better while it runs. It aims at a better allocation and doesn't guarantee a better result. It can also end with different versions favored for different visitors.

Which one to use depends on what the sprint is for. If you want to compare two specific versions and write down what happened, use the fixed test. If you care more about the page's results during the run than about the comparison, the adaptive test fits. Tests aren't the only source of lessons either, since interviews, analytics and sales feedback all feed the learning step.

Webflow also says the time a traditional test takes depends on your traffic and on visitor behavior. Changing a traditional test partway through starts a new interval, so decide on the variations before you launch it.

There are more possible changes than a sprint can hold, so the team has to choose what to work on next.

Lean Labs' growth-driven design program shows one way to make that choice. It runs in 30-day sprints on HubSpot. Each sprint starts by looking for friction in page behavior, in forms and calls to action, in CRM lifecycle stages and in feedback from sales. Opportunities are then ranked by expected pipeline impact, by buyer relevance and confidence, and by the effort the change requires.

Those two lists are different kinds of input. Page behavior, form results, lifecycle stages and sales feedback record what buyers did or said. Expected impact, confidence and effort are estimates the team makes.

We'd use AI mainly on the first kind. Summarizing a quarter of sales-call objections is the same job as summarizing interviews, and the same check against the source applies. We'd leave the estimates with the team. AI can put the supporting quotes and numbers beside each item on the list, which gives the team something concrete to argue about when it scores them. The metrics you track decide which numbers those are.

The last step of the cycle is passing lessons to sales and service. A summary that links back to its sources is easier to pass along, because a sales lead who doubts a finding can read the calls behind it.