Field Notes: What Happened When We Removed Two Steps From Web3 Onboarding

A note before we start

This field note is a composite example, based on patterns we see repeatedly in web3 onboarding flows. The specifics are adjusted, but the decisions, trade-offs, and lessons are representative of what happens when you simplify early user journeys.

The core question: what really happens when you remove just two steps from a web3 onboarding flow?

Context: a familiar Web3 onboarding story

Imagine a mid-sized Web3 product.

The core value: a dashboard and set of tools that help users take meaningful on-chain actions (staking, LP positions, or automated strategies).
The audience: crypto-curious but not full-time degens; smart, busy people who will not tolerate unnecessary friction.
The reality: strong interest at the top of the funnel, but steep drop-off between "connect wallet" and first on-chain action.

The original onboarding looked something like this:

Land on the homepage and click "Launch App".
Hit a network selection screen with multiple options and jargon.
See a "connect wallet" modal with several wallet choices.
Be asked to fund the wallet with the right token to pay gas.
Only then, access the core interface and start setting up a strategy.

On paper, each step made sense:

Network selection gave flexibility.
Wallet connect was required for any on-chain action.
Funding up-front avoided failed transactions later.

In practice, the analytics showed a different story:

High drop-off at the network selection step.
Another spike of drop-off when users were asked to fund the wallet before seeing any value.

Support conversations echoed the data:

"I was not sure which network to pick."
"I did not understand why I needed to deposit before I even saw what I could do."
"I was worried I would make a mistake and lose funds."

What we changed: removing and re-sequencing two steps

We did not rebuild the entire product. Instead, we focused on two steps near the start of the journey.

Step 1 - Network selection

Original behaviour:

Users had to choose a network before they could see anything meaningful.
The default view was a technical list of networks, each with little explanation.

What we changed:

Default network: most users were coming from one ecosystem anyway, so we set a sensible default and hid the network picker behind an "Advanced" toggle.
Contextual switching: users who needed another network could switch later, at the moment it actually mattered.

Effectively, we removed network selection from the immediate critical path and turned it into a contextual decision instead of a mandatory precondition.

Step 2 - Up-front funding requirement

Original behaviour:

After connecting a wallet, users were told they needed a specific token on the right network to continue.
The flow pushed them straight into acquiring or bridging assets before they had seen anything of the product.

What we changed:

Deferred funding: users could enter the main interface and configure a strategy or explore data without funding immediately.
Guided funding later: when users were ready to run an on-chain action, a focused prompt walked them through funding and fees.

We did not remove the need for funding; we moved it later, closer to the moment where users understood why it was necessary.

What happened after the changes

The short version: more users reached meaningful value, and the nature of support questions changed.

Behavioural shifts

After the changes, we saw patterns like:

More new users reached the first configured strategy or setup before encountering complex decisions.
Time-to-first-meaningful-action shortened, because users had a clearer mental model before they were asked to fund.
Fewer users abandoned the flow at the "I do not know what to choose" stage.

Instead of being forced into technical choices immediately, users experienced:

A clearer, more guided path into the core interface.
Time to understand what the product did.
A funding step that felt like enabling a decision they already cared about, not a hurdle.

Support and qualitative feedback

Support tickets did not disappear, but they changed character:

Fewer "I am stuck at step 2" messages.
More questions about strategy choices and risk, which are higher-value conversations.
Users reported that they felt more confident by the time they were asked to fund.

From a growth perspective, this mattered because:

Early friction dropped.
Conversations moved from "how do I get in?" to "how do I use this well?"
The team could spend more time on education and less on rescue.

What we learned

A few lessons emerged that apply beyond this single flow.

1. Sequence complexity after value, not before

Both network selection and up-front funding were real requirements, but they did not need to sit at the front of the queue.

Users are more willing to deal with complexity after they:

Have seen the interface.
Understand what they are trying to achieve.
Believe the outcome is worth it.

Moving complex steps closer to the moment of value often reduces perceived risk and confusion.

2. Activation needs a clear, behaviour-based definition

Before the changes, the team had a fuzzy sense of activation. After reworking the flow, they aligned around a clearer definition, such as:

"User has created and saved their first strategy, with parameters set."

This made it easier to:

Design the first-time flow around that event.
Measure progress.
Prioritise features and experiments.

3. Not all friction is bad, but it needs to be in the right place

Some friction is protective:

Explaining risk.
Confirming decisions that cannot be easily reversed.
Making sure users understand what they are doing with funds.

The problem is misplaced friction:

Asking for irreversible commitments before users understand the context.
Front-loading detailed configuration that could wait.

The lesson is not "make everything frictionless". It is "put friction where it earns trust and reduces regret".

4. Data without story is not enough

Analytics showed drop-offs at specific steps, but the decisions only made sense when combined with:

User interviews.
Support transcripts.
Observing people go through the flow live.

Quantitative data surfaced where people struggled; qualitative input explained why.

How to apply this to your own Web3 onboarding

You do not need to copy these exact changes. Instead, you can apply the same thinking to your own product.

1. Map the first session from the user's perspective

Ignore internal systems for a moment. From a user's point of view, list:

The first page they see when they click "Launch" or "Get started".
Each decision they are asked to make.
Each commitment (connecting, signing, funding).
The moment they first see something that looks like real value.

2. Label each step: essential now, later, or never

For each step, ask:

Is this truly essential before the user sees value?
Could this wait until they understand more?
Does this step exist for the user, or only for our internal convenience?

Look for steps that are:

Technically convenient but user-hostile.
Legacy choices that no longer need to be there.

3. Experiment with removing or deferring one or two steps

You do not need a full redesign to learn something meaningful. Start with a small experiment:

Remove a non-essential choice from the first screen.
Defer funding until after configuration.
Turn a mandatory choice into a sensible default with an "Advanced" option.

Define what you will watch:

Completion rate of early steps.
Percentage of users reaching your activation event.
Time-to-activation.

4. Update lifecycle messaging to match the new flow

If you change onboarding but keep emails and notifications the same, you will create new confusion.

Update any onboarding emails to reflect the revised journey.
Add in-app prompts that guide users through the simplified flow.
Make sure you are tracking new events correctly.

Where this sits in the bigger picture

This field note sits at the intersection of:

Onboarding and Activation - designing first-time experiences that get users to real value.
Product Growth - making product changes that support durable growth, not just aesthetics.
Growth Systems Diagnostic - using data and qualitative insight to decide which parts of the system to change first.

For a broader view of how onboarding fits into your overall engine, read: The 3-Layer Growth System: Product, Lifecycle, Distribution.

If you suspect your own onboarding is overcomplicated in the wrong places, a good starting point is a structured review. That is exactly what we do in a Growth Systems Diagnostic, before we recommend any sprints or larger engagements.