Why do people abandon a signup flow if they already chose to sign up?

Choosing to click "Sign up" only means someone was curious enough to start. It does not mean they trust you enough to hand over a password, a company name, and a credit card before they have seen anything work. Every extra screen between that click and a real result is a place where curiosity can run out.

What counts as a "drop point" in an onboarding audit?

A drop point is any screen or question where a real user pauses, re-reads, backs up, or closes the tab. It is not the same as a field that simply takes time to fill in. A field that everyone fills in without hesitating is not a drop point, even if it added a few seconds.

How many users do you need to watch to find real problems?

Five is usually enough to see the same one or two screens trip up most people, because usability research has repeatedly found that a handful of sessions surfaces most of the obvious problems in a flow. It will not give you statistically precise percentages, but it is not trying to. It is trying to show you where people get stuck, and five sessions almost always show that clearly.

What is the "aha moment" and why does onboarding need one early?

The aha moment is the first point where someone sees the product do the thing they came for, not a description of it, the actual result. A flow that asks for company size, job title, and a credit card before that moment is asking someone to trust a promise instead of showing them proof. Moving the aha moment earlier is usually a bigger lever than trimming any single field.

Is asking for a credit card upfront always a bad idea?

Not always. Some products need billing details early because the trial itself has real cost, or because the buyer is used to that pattern in that category. The mistake is defaulting to it because it is easier to build, without testing whether it costs you signups. Test it against a flow that defers billing past the first result, and let real behavior decide.

What is progressive profiling and how does it help onboarding?

Progressive profiling means collecting information over several visits instead of all at once on the first screen. You ask for an email and a password to start, let the person reach a working result, and ask for the rest, company size, role, integrations, after they already have a reason to keep going. It spreads the cost of giving information across moments when the person has more reason to pay it.

How is a user-research audit different from an A/B test of the signup page?

An A/B test tells you which of two versions converts better, but not why, and it needs enough traffic to reach a confident result. Watching five real users complete the flow tells you exactly where and why people get stuck, with no traffic minimum, and it works even on a flow that gets a handful of signups a week. The two methods answer different questions and work well together: the audit tells you what to build, the test confirms it worked.

Should every onboarding flow ask for the same amount of information?

No. A flow for a free consumer tool and a flow for a piece of software a company will run its finances through are not the same request, and they should not collect information at the same pace. The right amount of friction depends on what trust the product genuinely needs before it can do its job, not on a general rule to remove every field possible.

What is the single biggest mistake teams make when reviewing their own onboarding?

Reviewing it as the people who built it. Anyone on the team already knows what every field is for, already trusts the product, and already knows what happens after they click submit. A first-time visitor has none of that context, so a walkthrough by the team will miss almost every point of confusion a stranger would hit.

Does reducing signup friction mean asking for less information overall?

Not necessarily. It means asking for less information before the person has a reason to trust you with it. A flow can end up asking for the same total information as before, just spread across a first result and a handful of moments afterward, rather than front-loaded onto one form nobody has a reason to fill in yet.

Why Your Onboarding Flow Is Losing Signups: Reveneau

In the work we do, we look at a lot of signup flows before we touch any code. The pattern repeats often enough that we now expect it: the product is fine, the pricing is fine, and the flow between "click sign up" and "see the product work" is where people leave. Nobody built that flow to lose signups on purpose. It grew one field at a time, each one reasonable on its own, until the whole thing asked a stranger to trust the product before the product had shown them anything.

This is not a marketing problem. It is a design problem, and it has a specific, checkable cause: the order in which you ask for things.

The first mistake: asking before showing

Most onboarding flows are built backward. They ask for a name, an email, a company size, a role, sometimes a phone number, before the person has seen the product do the one thing they came for. Each question feels small to the team that wrote it. To a first-time visitor, every question is a small test of whether this is worth their time, and they have not yet seen a reason to say yes.

The Baymard Institute, which has studied checkout and signup abandonment across dozens of studies, found that 18% of people who abandon a checkout cite "the site wanted me to create an account" as a reason, among those who had gotten far enough to actually be checking out rather than just browsing. That number comes from e-commerce checkout, not software signup, but the mechanism is the same one: asking someone to commit before they have seen the payoff.

The fix is not "remove every field." It is: move the moment where someone sees real value earlier than the moment where you ask for anything that costs them effort or trust.

The second mistake: forcing an account before the first result

A related version of the same mistake is making account creation the gate itself. Set a password, verify an email, confirm a phone number, and only then are you allowed to see what the product does. Every one of those steps is a place where someone who was mildly curious can decide they are no longer curious enough.

Baymard's own account-creation research, drawn from a 2022 survey of 4,384 US adults, found that 24% of US internet shoppers had abandoned at least one cart in the prior quarter specifically because a site forced them to create an account before they could complete what they came to do. Again, that figure is from retail checkout. Software signup is not identical, but the underlying behavior, refusing a mandatory account step before trust has been earned, shows up in both.

The better order is: let someone reach a real result first, whether that is a working demo, an imported file, or a generated output, and ask them to create an account to save that result or keep going. At that point the account is not a toll gate. It is a reasonable next step, because they already have something to lose by not taking it.

A concrete audit method: watch five real people

You do not need a large study to find where your own flow breaks. You need five people who have never used the product, a screen recording, and permission to say nothing while they try.

Here is the method, in order:

Find five people who match your actual buyer, not five coworkers. A coworker already knows what the fourth field is for. A stranger does not.
Give them one instruction: "Sign up for this and get to the point where you'd start using it." Nothing more specific than that.
Watch without helping. Do not explain a confusing screen. If they get stuck, let them stay stuck, and write down exactly where.
Mark every drop point: any screen where they pause more than a few seconds, reread something, click back, or say something like "wait, why does it need this."
Count the drop points per person, then look for the one or two screens where three or more of the five people stumbled. That is not five separate small problems. It is one real problem that shows up five times.

This kind of small-sample walkthrough is a known method in usability research, not a shortcut invented to save time: watching a handful of real users complete a task reliably surfaces most of a flow's obvious problems, because the same one or two screens tend to trip up most people who were not involved in building the product. You are not trying to get a statistically precise conversion number out of five sessions. You are trying to find the one screen everyone stalls on, and five people is usually enough to make that screen obvious.

Once you have the drop points, rank them by how many of the five people hit them, not by how easy each one is to fix. The field your engineering team dislikes the most is not necessarily the field that is losing you signups.

What to fix once you have the list

Most audits like this turn up the same two or three categories of problem, and they are worth checking for by name.

Information asked for before it is needed. Anything the product does not actually need until later, company size, industry, number of teammates, can usually move to a later screen or disappear into a setting the person changes once they are already using the product.

A required account step before any output. If someone can see a real result of using the product before creating an account, let them. Ask for the account only when they want to keep or share that result.

Unclear reason for a question. If a field's purpose is not obvious, say why you are asking, in one short line next to the field. "We ask so we can set your default currency" costs one sentence and removes a reason to hesitate.

No visible progress. If the flow has more than two or three steps, show the person where they are and how much is left. Not knowing how many more screens are coming is itself a reason to quit.

None of these fixes require a redesign of the product. They require re-ordering what you already ask for, and cutting anything you are asking for out of habit rather than need.

It also helps to write down who owns each field on the form, and why it is there. If nobody on the team can answer why a field exists within a few seconds, that is usually the field to cut first. This is a smaller task than it sounds like: most signup forms have grown one field at a time over months, added by different people for different reasons, and nobody has looked at the whole list together in a long while. A short list with an owner and a reason next to each field turns that guesswork into a decision you can actually defend.

Where this fits in a build

When we scope a build, we treat the signup flow as its own piece of work, with its own eval suite checking that the path to first value stays short and that nothing new gets added to it without a reason. That is a deliberate choice, not a formality: a flow with no owner tends to grow a field at a time, the same way it usually got long in the first place.

The audit itself is worth repeating on a schedule, not just once at launch. A flow that was lean at launch can quietly regrow fields as new teams ask for new data points, each addition small enough that nobody flags it in review. Watching five real people go through the flow every few months, the same way you would run any other check before a release, catches that drift while it is still one or two fields, not ten.

The flow that wins is not the one that asks for the least. It is the one that asks in the right order.

Sources

Baymard Institute, Cart Abandonment Rate Statistics: supports the finding that 18% of checkout abandoners cite forced account creation as a reason for leaving.
Baymard Institute, Make "Guest Checkout" Prominent: supports the finding that 24% of US internet shoppers abandoned a cart in the prior quarter specifically due to forced account creation, based on a 2022 survey of 4,384 US adults.