Which tools help teams plan, test, and collaborate on growth-driven design?

Growth-Driven Design needs one tool for each recurring job in its build, measure, and learn cycle, and the official growthdrivendesign.com tool list is organized exactly that way [1]. For running the work it names Asana for most teams, Jira for teams on strict agile workflows, Slack for communication, and its own GDD Dashboard for tracking performance and the wish list [1]. For the site itself it recommends HubSpot as the CMS, described as built to drive company-wide growth rather than only store content [1]. For understanding users it points to a customized Google Analytics setup as the measurement baseline, Hotjar or Lucky Orange as an all-in-one behavior layer, UserTesting.com for sourced participant tests, Typeform for surveys, and Mixpanel or Amplitude for event tracking once page-level metrics run out [1]. For proving changes it lists UsabilityHub for quick click and five-second tests, and HubSpot A/B testing or Optimizely for split and multivariate experiments [1].

Some of the named products have shifted since that list was published, but the job structure has not. Hotjar now operates as part of Contentsquare [4], collaborative interface design has consolidated into Figma [7], and VWO has grown into a direct alternative to Optimizely for experimentation [6]. The practical rule is to buy for the job, not the brand: identify which of the six core jobs a tool covers before you compare features or price. A stack built this way stays small, because most teams need only one tool per job, and it stays honest, because every tool has to earn its slot against a specific step in the cycle instead of a broad promise about growth [1]. The sections below take each job in turn, name the tools that have a confirmed product page, and explain what the tool does and what to look for when you pick one.

HubSpot is the CMS the official GDD list recommends, because it lets a marketer publish and edit pages with a drag-and-drop editor and no coding, then reuse hundreds of themes and templates to ship changes fast [1][2]. That speed is the whole point of a GDD build tool: the continuous-improvement cycle only works if the person with the insight can change a page this week instead of filing a ticket and waiting for a developer sprint.

What to look for in a GDD CMS is editability by non-developers first, then a template or module system so new pages inherit the design without custom work, and native or easily integrated A/B testing so you can act on what analytics shows without leaving the platform [1][2]. HubSpot bundles all three, which is why it doubles as the experimentation tool for many early programs [1].

General-purpose builders can also fit if they clear the same bar. Webflow gives designers a visual canvas with a built-in CMS and hosting, and WordPress is an open-source platform that millions of sites run on, with plugins for testing and forms. The difference is integration: HubSpot keeps the CMS, analytics, and CRM in one account, while a Webflow or WordPress build usually means wiring analytics, testing, and a CRM together yourself. Choose on how much of that connective work your team wants to own, and on whether one login for content and data is worth more to you than a specialist builder's design freedom.

Google Analytics 4 is the measurement baseline for a GDD program, because it is free and answers the question every sprint starts from: how customers interact across your sites and apps throughout their entire lifecycle, in reports the whole team can read and share [1][3]. Each continuous-improvement sprint sets one focus metric, and analytics is where you watch it move.

What to look for is coverage of the specific numbers GDD acts on: entrance and bounce behavior on the pages people land on, exit points in the funnel, and conversion on offer pages, all sliceable by traffic source and audience [3]. GA4 covers this at no cost, which is why it belongs in the stack before any paid measurement tool.

Event-level products earn a place only after page-level metrics run out. Mixpanel and Amplitude, both on the official list, track individual user events and cohorts in depth, which matters for product-led sites and apps where a single page hides many distinct actions [1]. For a typical marketing site in its first GDD cycles, GA4 alone gives you enough signal to choose what to test next, and adding an event tool early tends to add cost and setup time before you have a question that needs it [1][3].

Behavior tools explain why the analytics numbers move, by recording exactly what people do on a page, and Hotjar is the all-in-one option the official list names first [1][4]. Analytics tells you a page has a high exit rate; a heatmap and a session replay show you the form field where people stall or the button they never reach.

Hotjar covers four behavior jobs in one install. Heatmaps show where users move, click, and scroll. Session replays let you watch real journeys and spot bugs, confusion, and drop-offs. Surveys with templates and an AI generator ask on-page questions, and unmoderated user tests capture people working through a task out loud [4]. That range is why GDD treats it as the research layer rather than a single-purpose add-on, and it now runs as part of Contentsquare [4]. Lucky Orange is the listed alternative for the same job [1].

What to look for in a behavior tool is the pairing of quantitative and qualitative views: aggregate heatmaps to see patterns across many visitors, plus individual replays to understand one person's path, plus a lightweight survey to ask users directly [4]. A tool that only draws heatmaps leaves you guessing at intent, and one that only records sessions makes the broad pattern hard to see. The value is having both feed the same test backlog, so a behavior insight turns into a specific experiment.

Experimentation platforms prove which change actually moves the focus metric, using a statistics engine that tells you when a result is real instead of noise [5][6]. Growth-Driven Design runs on tested decisions, so this is the tool that converts a heatmap hunch into a validated change.

Optimizely supports A/B, multivariate, and multi-armed bandit testing backed by its Stats Engine, and now generates test variations with AI so a change does not wait on a developer [5]. VWO offers A/B, split, and multivariate testing with a Bayesian statistics engine, a visual editor for building variations without development expertise, and built-in heatmaps and recordings so you can compare control against variation in one place [6]. Both are strong, and the choice comes down to whether you value Optimizely's enterprise experimentation depth or VWO's all-in-one testing plus behavior bundle [5][6].

What to look for is a trustworthy statistics engine first, because a test that declares a false winner is worse than no test, then a visual editor so non-developers can build variations, and enough test types to match your traffic [5][6]. Teams already on HubSpot can run native A/B testing before paying for a dedicated platform, and often should, until traffic volume and question complexity justify the upgrade to a specialist tool [1].

Figma is where a GDD team designs and prototypes pages before anyone builds them, in one shared file that stakeholders can comment on directly [7]. It replaced the older habit of emailing static mockups, and it is now used across most of the Fortune 500, which makes it a safe default for design collaboration [7].

Its fit for GDD is speed of feedback. Design and prototyping live in one place, multiplayer files let several people work at once, and comments attach to the exact element in question, so a launchpad page or a test variation can go from idea to reviewed prototype without a handoff delay [7]. That keeps the design step inside the same weekly rhythm as measurement and testing.

What to look for in a design tool is real-time collaboration, a component or design-system feature so pages stay visually consistent as the site grows, and prototyping good enough to test a flow before it is built [7]. Figma covers all three. The one caution is scope: a design tool plans the interface, it does not publish it, so it sits alongside the CMS rather than replacing the build step. Treat the Figma file as the source of truth for how a page should look, and the CMS as where that design goes live.

A shared board keeps GDD sprints on track, by giving the whole team one visible list of what is being tested, built, and learned, and Asana is the tool most teams reach for [1][8]. The official list also names Jira for strict agile workflows, Slack for day-to-day communication, and the GDD Dashboard for tracking site performance against the wish list [1].

Asana tracks work from start to finish so every team stays in sync and on schedule, and it is used by more than 170,000 organizations, which means integrations and templates are easy to find [8]. For GDD its job is to hold the prioritized wish list of ideas and move each one through the sprint from planned to building to shipped to measured [1][8].

What to look for in a board is a clear prioritization view so the highest-impact ideas surface first, task ownership and due dates so a sprint actually closes, and integration with the rest of the stack so a test result or a new idea does not get stranded in someone's inbox [1][8]. The specific tool matters less than the discipline behind it: without one visible backlog, the continuous-improvement cycle quietly stalls between sprints, and the site drifts back toward the launch-and-forget pattern GDD is meant to replace.

Match the stack to your current traffic, not your ambitions, and add tools in the order the cycle actually needs them [1][4]. Measurement and behavior tools come first, because Google Analytics and a tool like Hotjar produce useful insight at any traffic level, while a dedicated testing platform only pays for itself once pages get enough visitors for experiments to reach statistical validity [1][3][4].

Use the built-ins before the add-ons. A CMS like HubSpot already includes drag-and-drop editing, templates, and native A/B testing, which covers both the build step and early experimentation without a second subscription [1][2]. Add a dedicated platform such as Optimizely or VWO when you need multivariate tests, a stronger statistics engine, or server-side experiments the built-in cannot run [5][6].

Consolidate where one tool covers several jobs well. Hotjar folds heatmaps, replays, and surveys into a single research layer [4], and VWO bundles testing with behavior analytics [6], so a small team can cover four jobs with two tools. The one purchase that is never optional is the shared board, whether Asana, Jira, or the GDD Dashboard, because the sprint cadence falls apart without a single list of what the team is testing and why [1][8]. A quick test for any new tool: name the job it does and the tool it replaces. If it does neither, it is overbuying.