Sign-Up and Onboarding: What to Ask and What to Skip

Ask a question in sign-up or onboarding only if the answer changes what the person sees in their first session, and ask it at the moment they can tell why. Everything else can wait or be dropped. Apply this to every field, permission and preference screen, and onboarding gets shorter without losing the information you actually use.

Most onboarding grows the same way: each team adds the one thing it needs. Marketing wants a source, product wants a goal, support wants a phone number. Nobody removes anything. The result is a flow built around the company's needs rather than the first session of the person using it.

What is the test for each question?

For every field, permission and screen in your onboarding, answer three things:

1. What changes in the first session if the answer is known? A different home screen, different content, a working feature. If nothing changes, it is a candidate to defer.

2. Can the person tell why we are asking? If not, add a reason or move it to a moment when it is obvious.

3. What happens if they skip it? If the app still works, let them skip.

This gives you three outcomes: keep it, ask it later, or cut it.

What is worth asking up front?

The things that decide the first experience. Hue, a culture-based dating and community app, opens with a step-by-step wizard, one decision per screen, labelled "Step N". It goes straight to the choice that defines the product: dating, community, or both. From there the wizard branches by mode. The first question is the one that shapes everything after it.

Wheel asks a lot more. The onboarding is a structured journey of more than 15 screens that builds a detailed candidate profile, because the product matches people on soft skills, values and communication style, and the profile is what that matching works from. It ends with a "Strength Levels" view that gives the person an immediate insight before they browse roles. The length is justified because the questions are the product, and the person gets something back for answering.

The lesson is not "keep onboarding short". It is that every question should earn its place by what it does for the person.

What can usually wait?

• Account creation when the app can show value first.

• Notification and contact permissions until the moment the feature needs them.

• Profile completeness: photo, bio, optional details.

• Marketing questions such as "how did you hear about us", unless you act on the answer.

• Preferences that can be learned from behaviour.

Deferring is not hiding. Give people a clear place to complete the rest, and remind them when it is useful.

What should you always provide?

• A reason next to anything personal or a permission.

• A visible sense of progress so people know how long it will take.

• A fallback when something fails. On Wheel, one of the problems we fixed was the inability to enter data manually when a LinkedIn import failed.

• A useful first screen after sign-up. In Lit, an app for meeting people through activities, a first-time user with no activities yet sees an empty state that points straight into Discover, not a dead end.

How do you decide when two teams disagree?

Put the questions in a list and give each one the three-part test. Where the team still disagrees, run the flow with and without the question for a small group of users and compare what happens at that step and afterwards. A question that the team "needs" for later reporting is usually better asked later, after the first value.

What to do this week

1. List every field, permission and screen in your sign-up and onboarding.

2. Run the three-part test on each.

3. Mark each as keep, ask later or cut.

4. For each "keep", check a reason is visible.

5. Look at what a new user sees right after sign-up. If it is empty, plan the first screen.

FAQ

How many onboarding screens is too many?

There is no number. Wheel uses more than 15 and it works for that product because each answer shapes the matching. What matters is whether each screen earns its place.

Should I let people skip onboarding?

If the app works without it, yes. Where it does not, explain why each step is needed.

Do I need to collect an email or phone number at sign-up?

Only if you use it in the first session, for example to verify identity or send a code. Otherwise ask later.

If you want help deciding what stays, see our mobile UX/UI design work, or book a free 30-minute Product Diagnosis. If you are not sure where people leave, start with why users drop off during onboarding.