Test your onboarding before real users find the problems

You have been through your own signup more times than any customer ever will, with an account that already has data, settings and context. The empty dashboard a new user lands on is the version of the product you look at least.

Onboarding problems are also the quietest. A visitor who gives up on a landing page might tell you. Someone who signs up, sees an empty screen that explains nothing, and never comes back usually does not.

1. 01 · Signup

   A user whose mission needs an account creates one, with its own details, where your product offers self-serve signup.

2. 02 · Verification

   A confirmation code or link sent by your product is read from a test inbox and used, the way a person would copy it from their email.

3. 03 · Onboarding

   Whatever comes straight after: setup steps, questions, an empty state, a tour or nothing at all.

4. 04 · First value

   The user carries on toward the outcome it came for — the first project, the first import, the first result — and the report says how far it got.

• ·5 users, each with a mission and a success condition written as an outcome — never a route through your product.
• ·Each user whose mission needs an account gets its own generated identity: its own email address, password, name and company. Generated identities are never shared, so one user’s single-use sign-in code cannot lock out another.
• ·Email verification is handled automatically and recorded as the test’s doing. A verification that fails is treated as our limitation, never as evidence about your product.
• ·A user counts as signed in only when the browser has objectively got inside — past the sign-in and verification screens, with no error.
• ·Up to 28 actions and 5 minutes of each user’s own time; waiting for an email does not count against it.
• ·The report covers what users met after creating an account, with what to change, a fix prompt, and one re-test.

A Full Scan may create up to one test account per user whose mission needs one. Anything a user saw after signing in is never included in a shared report link, because inside your product it may be looking at data you cannot consent to publish.

• –Bypass a CAPTCHA, bot protection or human-verification check. It reports that the test stopped there.
• –Make payments, enter card details or buy anything. Card fields are never filled.
• –Invite real people, or send messages to anyone.
• –Connect third-party accounts or credentials. Navigation off your site is refused, so there is no sign-in through another service and no third-party integration.
• –Delete, publish or take destructive actions. A user may undo only what it made itself in the same visit.
• –Get past SMS codes, single sign-on only signups or invitation-only access. These are reported as limits of the test.

A Full Scan builds on a free scan of the same product: it starts from what the free scan established about your product and goes past it. The free scan stays on your public pages and takes a few minutes. If it shows you something worth fixing already, that is the cheapest possible time to find out.