Improving activation by cutting onboarding from 21 steps to one

Research suggested Intruder's onboarding was holding trials back, and an A/B test built in under 30 minutes confirmed it. I then redesigned the trial around one goal: a serious vulnerability in front of new customers within minutes, not after an hour-long scan.

Role
Lead designer and project lead; owned product direction after the test, with no PM on the work
Collaborators
Product squad, VP Product, CEO, Data, Engineering
When
Q1 2025 test; final form Q1 2026
Results
  • +37% customer activation after the full release, following +30% in the initial test
  • +53% licences bought at activation
  • ~5 min to cloud check results after connecting a cloud account, against about 71 minutes for a standard scan
Key decisions
  1. I proposed removing onboarding entirely rather than condensing it, and made that testable by agreeing the decision rule in advance: keep the change unless conversion fell by more than 1%. Winning that argument took the better part of a year, first with my manager, the VP Product, and then, at his suggestion, the CEO.
  2. After the test, I made cloud accounts the default way to start a trial, because cloud checks published their full results, at every severity, within about five minutes, and a serious finding was the strongest signal we had that a trial would convert to a paid plan.
Intruder onboarding: target type selection and scan progress UI

Context

Everyone agreed the free trial could work harder, but nobody had looked closely at the data, so after reviewing the marketing site's conversion I took it on myself to investigate.

Intruder had a 21-step onboarding flow covering everything from inviting colleagues to reviewing scan results. About 1% of trials completed it, and more than half didn't get past the second step.

Pre-trial churn: why visitors left the site without starting a trial

Observations

  • Traffic was down on the previous year.
  • When traffic rose again, sign-ups did not rise with it.
  • The pricing page was blamed, but it produced too few trials to explain the decline.

Structural issues

  • No history. Analytics kept no record far enough back to test claims about past changes, so keep one outside Google Analytics, starting with a basic funnel.
  • No way to test. Marketing could not experiment without help from other teams, so adopt an A/B testing tool, micro-surveys and interviews with prospects.
  • No owner. Nobody was responsible for the site's conversion, so appoint someone to monitor, test and report on it.

Operational issues

  • Make the top-level navigation links interactive.
  • Review landing pages for relevance to the audience arriving on them, and design for mobile first.
  • Invest in lead magnets to bridge the gap between browsing and starting a trial.

Pricing page

  • Break up the content, and minimise or remove the licence sliders.
  • Frame the plans around the job each customer needs done, and lead with benefits rather than features.
  • Test alternative designs for the page.
The structural issues row of the original pre-trial churn board: absence of monitoring, of research or optimisation, and of oversight, each with its written proposals Part of the original board
Redrawn from my review of the marketing site, which came before this work. On the board each issue carries a written proposal, and a competitor analysis follows.

The problem

The flow walked users through adding colleagues, adding targets, starting a scan, configuring integrations, reviewing results, fixing vulnerabilities and running a confirmation scan. Each step had been chosen for its correlation with activation and its logical place in the sequence, which was well-intentioned but built around assumed behaviour rather than observed behaviour.

The old Intruder Getting Started onboarding flow showing the adding targets step
The existing onboarding flow, here on the “Adding targets” step, one of 21. The sidebar progress tracker shows how much remained.

Share of trials reaching each point in the old onboarding

The original onboarding analysis board, with the funnel, the conversion evidence and the experiment hypothesis The original board
Selected steps from the onboarding funnel on my analysis board, measured over 30 days before the test. The board counts the flow’s nine top-level sections; this page counts its 21 steps. Most people who went on to buy did what they needed outside the flow.

Research and insight

Session recordings showed many users skipping around the flow or ignoring it entirely, and interviews with recently activated customers surfaced three consistent patterns:

  • Preference to roam. Users explored the platform themselves and consciously avoided onboarding.
  • Inbuilt inertia. Onboarding slowed customers down on the way to the job they had come to do.
  • The job undervalued. The flow taught features rather than the task customers were hiring Intruder for.

The interviews also showed what made a trial click, which was a scan finding something real on the customer's own infrastructure. Earlier analysis for our metrics framework had already shown that trials finding any vulnerability converted to a paid plan at 10.27%, against 2.88% for those finding none. I took the interview evidence to our business intelligence team, who confirmed that severe findings, those rated high or critical, raised the likelihood of converting further still.

That gave the trial a clear goal: put a serious finding in front of new customers as quickly as possible. The biggest obstacle was scan time, because a standard vulnerability scan took about 71 minutes on average, a long time to hold the attention of people who were leaving by step two.

A competitive review of seven similar products found an average of about nine steps, and a large minority had no formal onboarding at all, so both approaches favoured momentum over instruction.

Current state

  1. 1Trial creationHopeful, curious
  2. 2Welcome / EntryMildly confused, unsure what to do
  3. 3Initial setupFrustrated/confused if unclear what scan to run
  4. 4Scan startBored, possibly discouraged
  5. 5Mid-onboardingTentative interest, mild hope
  6. 6First resultRelief or excitement (if issues found)
  7. 7Sign upPragmatic, weighing up effort vs outcome

4. Lowest point The lowest moment is when the scan has started but the user is locked out or forced to wait without clear next steps.

6. Highest point The highest moment is right after seeing actionable results: this is our lever.

The original current state journey map board, with rows for user goals, actions, emotional state, feeling, pain points and opportunities across each stage The original board
Redrawn from the current-state journey map: how a trial felt at each stage, from sign-up to conversion, with two notes from the board’s pattern summary. The full board also charts goals, actions, pain points and opportunities.

Strategic reframe

The internal preference was to condense the flow, which felt safest and matched what competitors did. I argued for removing it entirely, and for testing that before committing to a direction.

Intruder had no infrastructure for redirect tests, and the culture wasn't yet comfortable experimenting at this scale. I gave a talk to the company on how growth works, arguing that a business still finding what works learns more from bold tests than from refining what it has, with this test as the example. Even so, making the case took the better part of a year, first with the VP Product and then, at his suggestion, with the CEO directly.

What moved the conversation was not a stronger argument for self-service but a question the CEO could accept on his own terms. He expected removing the flow to do damage, so we agreed how much would be too much: if conversion fell by more than 1%, onboarding would come back. He then asked whether I would bet £100 of my own money that it wouldn't fall that far, and then £1,000, and both times I said yes.

The experiment, as agreed

Hypothesis
For new trials, removing onboarding and dropping people straight into the product will not lower the rate of conversion to a paid plan by more than 1%, and will get them to their first scan results sooner.
Test
Half of new trials, chosen at random, skip onboarding.
Measures
Conversion from trial to paid plan first, then the median time to first scan results.
Decision rule
If conversion falls by no more than 1% and results arrive sooner, redesign onboarding from scratch around the time to first results. If it falls further, restore onboarding and test lighter versions instead.

The objections I expected, and my answers

Won't this confuse or frustrate new users?
It might, so we would watch support requests and feedback from the test group. Any struggle would show us where guidance was essential.
What if it hurts long-term retention?
The test was there to inform a redesign, not to remove onboarding for good, and we could track retention and feature use over time.
Isn't it risky to give half of new trials no onboarding?
Yes, which is why I proposed keeping it short, limited to new trials and watched closely enough to revert quickly. A test meant to discover something should carry some risk.
How will this help us design better onboarding?
It shows the shortest path to value: where people need support, and what they find for themselves.

What it would teach us either way

  • Whether onboarding itself was causing people to drop off.
  • Which steps people found without being told, and which needed guidance.
  • A baseline to measure any simpler flow against.
The original rationale board: what the test would teach us, the objections and answers, and possible solutions it could lead to The original board
Redrawn from the board I used to win approval. The test was there to settle where the redesign would start: condensing the existing flow, as the team first preferred, or removing it, as the analytics and my interviews suggested. Few trials engaged with the flow, and one user told me they just wanted it out of the way. The board gives the pass threshold as one percentage point, but the rule we agreed in advance was a relative fall of more than 1%.

The test

Once approved, the test took under 30 minutes to build. Half of new trial customers went straight from sign-in to the dashboard's existing empty state, with no onboarding and no other changes, so the test isolated the effect of removing onboarding alone. I proposed running it for two weeks, because a change this large should show a big movement or none at all, and the lift was clear within that time; leadership kept it running for six weeks to be certain.

Old Intruder dashboard empty state showing 'Nothing to see here' message with Add target CTA
The empty state that half of new trials landed on after sign-in, unchanged from production. No onboarding flow, just the product.
−78% Reduction in time to activate
+33% Increase in monthly recurring revenue from ideal customer profile accounts
+30% Customer activation in the initial test
+25% Increase in first targets added

After the test: chasing the first serious finding

The test showed the old flow wasn't working, but an empty dashboard wasn't a destination either. There was no product manager on the work at this point, so I set the direction myself, got sign-off from the VP Product and built it with the squad.

I made cloud accounts the default way to start a trial because they served the trial's goal in three ways:

  1. More targets, less effort. Connecting a cloud account found a customer's infrastructure reliably and brought it in without manual entry.
  2. Faster results. Cloud container checks, which look for weaknesses such as misconfigured containers, ran far quicker than a standard vulnerability scan. Every check, passed or failed and at every severity, was published together within about five minutes of connecting, so any high or critical finding reached the customer then rather than after a wait of around 71 minutes.
  3. The right moment, sooner. My growth work had taught me how much the perceived moment of value matters, and a serious finding in the first few minutes put that moment in front of trialists while they were still paying attention.
Time to first results for a new trial, drawn to scale.

This was self-initiated. Cloud container scanning was still being built when I was looking for ways to cut the time to a first completed scan, and once I learned how much faster those checks ran, I prioritised bringing them into the trial.

What shipped

I mapped an ideal future state and scoped improvements in tiers by effort and impact, and three changes shipped:

  • An intent-based empty state. “Nothing to see here” became four ways to start: cloud assets first, then external infrastructure, web applications, or a demo target for anyone not ready to connect.
  • Early findings during the scan. The scan progress view showed findings as they emerged, so customers saw value before a standard scan finished.
  • Recurring scans by default. The scan setup defaulted to recurring, so new customers were set up for ongoing monitoring from day one.
The new Intruder empty state, Add and scan targets, with four ways to start: cloud assets (recommended), external infrastructure, external web application and a demo target
The empty state that replaced “Nothing to see here” (shown in the test above): four ways to start, with cloud assets recommended first and a demo target for anyone not ready to connect.

Before

The old scan in progress view: a single progress bar above a scrolling log of the checks being run, such as a Cisco TelePresence vulnerability marked critical

After

The new scan progress view at its second of four stages, target scanning: 153 of 250 scans complete across five scanners, and five early findings listed while the scan runs, led by a critical SQL injection
The scan progress view before and after, from my design files with demo data. The old view showed one bar and a log of checks. The new one moves through four named stages, from preflight checks to target scanning, and lists findings as they emerge, so customers don't wait ~71 minutes for their first signal of value. This is the final form, from Q1 2026, after the discovery flow was connected.
Scan setup modal showing recurring scan configuration with weekly, monthly and quarterly options
The scan setup modal, defaulting to recurring scans so new users were automatically positioned for ongoing monitoring from day one.

Possible future state

  1. 1Intent captureFeels seen and directed
  2. 2Quick setupConfident and in control
  3. 3Value previewReassured, engaged
  4. 4First winValidated, in control
  5. 5Path splitsProduct fits their workflow
  6. 6Expansion touchpointsReflective, primed for conversion

3. While the scan runs While the scan runs, show what it has found so far, such as how many assets it has seen and the common vulnerabilities among them.

4. First win Provide a summary card of critical issues + suggest action: “Download report” / “Send to Jira” / “Fix now”.

The original future state journey map board, with rows for user goals, actions, emotional state, feeling, pain points and design improvements across each stage The original board
Redrawn from the possible future-state journey map: a journey built around intent capture, fast time-to-value, and contextual deepening after the first win rather than before it, with two of the board’s design improvements.

Outcomes

The test validated the direction, and the changes that followed drove further gains in the months after release.

+150% Increase in external targets added in trials
+53% Increase in licences bought at activation
+37% Increase in customer activation after the full release, following +30% in the initial test Initial test Full release

Most of the gain came from customers adding more targets and licensing them at sign-up, which followed from the emphasis on external and cloud targets. With median annual recurring revenue per customer of roughly $3,100, even modest improvements in activation compounded quickly into revenue.

Reflections

The hardest part of this project was the advocacy rather than the design, because I was asking a company without a testing culture to bet on removing something it had invested heavily in building.

Getting that approval set a precedent beyond this project, since questioning a past investment on evidence, rather than defending it, became a norm the team could build on.

The second lesson was about which moment to design for. Research told us a serious finding was what convinced trialists, so the work became less about explaining the product and more about bringing that moment forward. Scan duration also became a metric the company monitored and actively managed.

← Metrics framework Next: Newsflare →