SaaS onboarding checklist: the stops to test

You test each screen when you build it, and each one passes. The break sits in the handoff between screens, which no single screen shows. You also skip the path as a new user, because your account already has projects and a saved card. A new user meets the handoff cold: the link opens in a different browser, the first login lands on an empty screen, and a setup question asks for a number they do not have. Nothing throws an error, so the drop looks like a lack of interest.

• Sign-up accepts a work email with a plus sign and names the field when it rejects one.
• The confirmation email arrives and its link logs the new user in, in the same browser or a new one.
• The first screen after login gives one task to do, not an empty dashboard with a faint Create button.
• Each setup question has a skip, a default or a plain reason it is asked.
• One real action, such as saving the first item, finishes without a detour through settings.

The first stop is the form, and the second is the email. A stranger types an address they use at work, and a plus sign or an unusual domain can get rejected by a rule written around the owner's own address. One failure is the link opened somewhere else. The visitor signs up on a laptop, opens the email on a phone, and the account is confirmed while the phone stays logged out. It lands on a sign-in page it did not expect to see.

Check this yourself as well. Open the same link in a private window and in a second browser. A visitor's run shows the step it reached, so when the link lands on a sign-in page you see that step and its screenshot. A short note on that screen, saying the account is confirmed and offering a sign-in button, can stop the second guess. The note costs a line of copy.

Onboarding flow testing

An empty dashboard with a faint Create button reads as a product with nothing in it. The visitor cannot tell whether the first item should come from an import, a template or a blank form. Good onboarding puts one named task on the first screen, such as adding the first receipt, and lets the user finish it without going anywhere else. The test shows whether the visitor saw that task or wandered into settings.

Look at what the first screen asks for, an action or a decision. A decision, such as which plan, which integration or which team size, freezes a new user who has not used the product yet. An action, such as add one item, moves them. Put the decisions after the first action, where the user already knows what the product does.

Every setup question costs a new user effort, more when it asks for something they do not have to hand. A billing contact, a tax number or a list of colleagues' emails is the usual trap. Give each question a default, a skip or a plain reason, so the visitor can reach the thing that matters first. Then check the first real action. If saving the first item asks for one more setup step, the finish line has moved, and the checklist has not caught it.

Finish the checklist on a single action. The path is done when the new user has done the thing the product is for, once, not when the settings page is complete. A stranger who sees the first item saved knows what the product does. One who sees a finished profile still does not. That is why the whole path needs a test, not each screen on its own.

A simulated visitor cannot sign in with Google or single sign on, so a test of those buttons stops at the provider's page. It cannot enter a real card, so a paid upgrade stops at the payment step. Run one real sign-up with a Google account and one real upgrade with a card you own, then watch the welcome emails for a week to see whether they bring people back.

Onboarding changes with every release: a new setup question, a moved tutorial, an email sender that switched domains. Each change can strand a new user without an error on the screen. Rerun the same visitors after each release, on a preview address. A GitHub Action can run them on each preview deploy.