Framework ⚡ Medium

Growth-Driven Design

Launch faster. Learn continuously. Let data drive the redesign.

Website Redesign Landing Page Optimisation Continuous Improvement SaaS Websites Conversion Optimisation Data-Driven Design

01 — TL;DR

Two sentences.

Growth-Driven Design (GDD) is a systematic approach to web design and ongoing site improvement that replaces the traditional full redesign cycle — a months-long project that launches a fully specified site into the real world — with a phased model: a strategic foundation informed by user data, followed by a rapid launch of a minimum viable website, followed by continuous monthly sprints of data-driven iteration that improve the site based on what real users actually do rather than what the design team predicted they would do. The framework was developed by Luke Summerfield at HubSpot in 2015 as a response to the consistent failure of traditional redesign projects to deliver promised results — projects that ran over time, over budget, launched on assumptions that real users immediately invalidated, and then sat unchanged for another three years while the competitive landscape evolved around them.

For design and marketing teams, GDD's most important contribution is the reframing of success: traditional redesign measures success by project completion — did we launch on time and on budget? GDD measures success by user impact — are real users doing what the site needs them to do, and is that rate improving sprint over sprint? This shift from output measurement to outcome measurement changes what the team focuses on, what they build, and how they justify their work to stakeholders — making GDD as much an organisational practice change as a design methodology.

02 — When to Use

Apply this when…

→ A website redesign is being planned and the team has an opportunity to propose a smarter approach than a traditional six-to-twelve month waterfall project

→ A recently launched site is underperforming and the team needs a structured framework for continuous, data-informed improvement rather than another full redesign

→ A SaaS company's marketing site needs to be kept current with the product as the product evolves — a continuous improvement model is better suited than periodic large redesigns

→ Stakeholders are sceptical of long design projects with uncertain ROI — GDD's sprint cadence produces measurable, attributable improvements each month rather than a single high-stakes launch

→ The team has access to web analytics, heatmaps, and user behaviour data but no structured process for translating that data into design decisions

→ The organisation is transitioning toward data-driven decision making and needs a framework that makes design work demonstrably tied to user outcomes

When NOT to apply it

Skip it when the site has insufficient traffic to generate statistically meaningful behavioural data — GDD's iterative model depends on user data from real visitors. Also skip it when the site is a brand-new product with no prior user data, when the organisation requires complete design sign-off before any page goes live (GDD's rapid launch model is incompatible with long approval processes), or when the product is a single-purpose transactional tool where the primary design goal is a one-time task completion rather than an ongoing relationship with visitors.

03 — How It Works

The mechanism

Growth-Driven Design works in three phases. The strategy phase builds the foundation: deep research into user goals, business objectives, and current site performance that produces a prioritised wishlist of improvements and a clear picture of what the launch pad site needs to accomplish. The launch pad phase builds and ships a minimum viable version of the site — better than the current site, good enough to learn from, fast enough to launch within weeks rather than months. The continuous improvement phase runs ongoing monthly sprints — each sprint using data from real user behaviour to identify the highest-impact improvement to test, implementing and measuring it, and using the result to inform the next sprint.

Traditional redesigns fail systematically

Research by Luke Summerfield and the HubSpot team on website redesign outcomes established a consistent pattern: traditional redesign projects take six to twelve months to complete, are typically over time and over budget, and launch with assumptions about user behaviour that are invalidated within weeks of going live. The core failure mode is the assumption that a team can predict how real users will behave on a new site before any real users have seen it. GDD's response is structural: rather than attempting to get the design right before launch, it launches something good enough to learn from and then uses real user data to get progressively more right over time.

The launch pad site is not a compromise

The most common GDD misunderstanding is that the launch pad site is a lower-quality version of the "real" site. This misunderstands the framework's epistemological logic. A launch pad site built on research-backed assumptions and launched quickly is more likely to serve users than a full redesign built on the same assumptions and launched six months later — because the launch pad site reaches real users while the assumptions are fresh and the team is primed to learn, rather than after months of accumulated investment that makes the team reluctant to change what they built. The launch pad is not a shortcut to the real site; it is the beginning of a learning cycle that produces a better site than any upfront specification could have designed.

Monthly sprints only work if the hypothesis is defined before the sprint

GDD's continuous improvement phase is not a process of making changes and seeing what happens. Each sprint follows a structured hypothesis cycle: identify the highest-impact question about user behaviour, formulate a specific hypothesis, implement the change as a test, measure the result against the hypothesis, and document the learning regardless of whether the hypothesis was confirmed or refuted. Teams that implement changes without a pre-defined hypothesis cannot determine whether the result was caused by the change or by other variables, cannot learn reliably from negative results, and cannot build the cumulative body of knowledge about their users that makes each successive sprint more valuable than the last.

How to measure it — sprint performance, cumulative learning, and compounding improvement

GDD produces three types of measurable output. Sprint performance measures whether each sprint's hypothesis was confirmed or refuted and what the magnitude of the effect was. Cumulative learning tracks how the team's understanding of user behaviour has improved over multiple sprints — are later hypotheses more accurate predictors of user behaviour than earlier ones? Compounding improvement tracks whether the site's core metrics are improving over time at a rate that exceeds what periodic full redesigns typically produce — the argument for GDD over traditional redesign is that continuous incremental improvement compounds into a larger gain than a single large redesign followed by a multi-year static period.

GDD vs CRO

Growth-Driven Design and Conversion Rate Optimisation (CRO) are related but distinct practices. CRO is specifically focused on improving conversion metrics through A/B testing of specific page elements. GDD is a broader framework that includes CRO techniques but extends to the full cycle of strategy, launch pad development, and continuous improvement across all user experience goals, not just conversion metrics. A team running GDD will use CRO methods within their sprints; a team running CRO without GDD's strategic framework may optimise individual pages without a coherent picture of the overall user experience they are building toward.

04 — Real Example

HubSpot's own website and the data that challenged every assumption

HubSpot applied GDD to their own marketing website as part of developing the framework — using their site as a live laboratory for testing whether the continuous improvement model produced better outcomes than the traditional redesign approach they had used previously. The strategy phase produced a prioritised list of improvements based on user research, heatmap data, and analytics. The launch pad site went live in weeks rather than months. The first sprint's hypothesis — that moving the primary CTA higher on the homepage would increase qualified lead generation — produced a statistically significant improvement.

The cumulative effect of twelve months of monthly sprints was measurably larger than the team's best projection for what a full redesign would have produced in the same period. More importantly, several sprint hypotheses were refuted — the data showed that changes the team had been confident would improve metrics actually reduced them — and these refuted hypotheses produced as much learning as the confirmed ones. The team discovered, through sprint data, that their homepage visitors were segmenting into distinct job types with different primary goals, a finding that no amount of upfront research had surfaced because it only became visible when real users behaved on the live site.

HubSpot · 2015–2016

Continuous sprint data surfaces insights no upfront research could have predicted

Doing it right — 12 months of compounding improvement

05 — In the Wild

Test yourself & see real examples

No examples yet — be the first.

Spotted a website that clearly improves continuously based on user data — or one that launched a full redesign and has been sitting unchanged for three years while the design trends and user expectations around it have moved on? Submit what you observed.

✓ Reviewed before publishing ✓ Your name on every example you submit ✓ Violation or fix — both welcome

Seen Growth-Driven Design applied well or ignored in a real product? Help grow the evidence base.

06 — Common Mistakes

Where teams go wrong

✗ Treating the launch pad as a permanent compromise rather than a learning platform. Teams that launch a GDD launch pad and then feel embarrassed by its simplicity have misunderstood the framework's purpose. The launch pad is not a permanently reduced version of the ideal site — it is the starting point of a continuous improvement cycle that will produce a better site than any upfront full redesign. Reframe the success metric from "how complete does this look?" to "how much are we learning and improving?"

✗ Running sprints without a predefined hypothesis. The most analytically damaging GDD mistake is implementing changes during a sprint without specifying beforehand what the change is expected to produce and why. Without a pre-specified hypothesis, the team cannot distinguish between a change that improved a metric and an improvement that occurred for unrelated reasons. Every sprint must begin with a written hypothesis: "We believe that [change] will [measurably improve metric] because [user behaviour insight]."

✗ Optimising sprint metrics that do not connect to business outcomes. GDD sprints that optimise for easily measurable metrics — page views, time on site, scroll depth — without connecting those metrics to business outcomes produce impressive-looking sprint reports and no business improvement. A sprint that increases time on site by 40% by adding distracting content is not a successful sprint if it reduces the conversion rate. Every sprint metric should be traceable to a business outcome.

✗ Skipping the strategy phase and going straight to sprint iteration. Teams eager to adopt GDD's iterative model sometimes skip the strategy phase — the research and planning that produces the user insights, business objectives, and prioritised wishlist that make the sprint decisions coherent. Without the strategy phase, sprint decisions are made based on whatever the most recent data suggests rather than within a framework of what the site needs to accomplish. The strategy phase is not overhead — it is the foundation that makes the sprint work accumulate into a better product rather than into a collection of individually optimised elements with no coherent direction.

07 — Variations & Related Principles

Connected ideas

Growth-Driven Design is a framework for continuous, data-informed website improvement. Its closest relatives are the frameworks and methods that share its commitment to iterative, evidence-based design rather than upfront specification.

The most important pairing is GDD with A/B testing. GDD provides the framework — strategy, launch pad, continuous sprint cycles — and A/B testing provides the statistical method for validating sprint hypotheses with sufficient rigour to produce reliable learnings. GDD without A/B testing produces a structured iterative process whose conclusions are anecdotal. A/B testing without GDD's strategic framework produces statistically rigorous tests on elements optimised without a coherent picture of what the site needs to accomplish. Together they produce an improvement cycle that is both structured and statistically reliable.

08 — 10-Min Exercise

Run it right now

⏱ 10 minutes · Solo · No prep

The Assumption Audit

1. Open your most important web page — your homepage, your primary landing page, or your product's main entry point. Write down the three assumptions the current design is built on. Examples: "users will scroll past the hero to read our feature descriptions," "users who arrive from paid search already know our category and just need to see pricing," "the primary CTA in the hero section is where most users start their evaluation."

2. For each assumption, rate your confidence on a scale of 1 to 3: 1 = we have data confirming this from user behaviour, 2 = we have indirect evidence suggesting this, 3 = we assumed this when designing and have never validated it.

3. For every assumption rated 3, write the sprint hypothesis that would test it: "We believe that [change to address the unvalidated assumption] will [measurable outcome] because [user behaviour logic]." Be specific — not "we will improve the page" but "we will move the feature benefit bullets above the testimonials and expect to see a 10% increase in scroll depth past the CTA because users need to understand the value before testimonials are relevant."

4. Count how many of your page's core assumptions are rated 3. If more than one foundational assumption has never been tested with real user data, your page is built on an unvalidated foundation — and GDD's continuous improvement model is the structured way to build that foundation sprint by sprint rather than in another full redesign.

10 minutes