A new user signs up, lands in an empty account and has to figure out where to start. Some do. Many leave. Onboarding is the work of getting them from an empty screen to their first real result.
For more on this topic, read How Product-Led Teams Can Use an Interactive Demo Before the Trial, How Founders Can Show Product Progress in Investor Updates and How Small Sales Teams Can Build a Shared Demo Library.
Short Answer
Use short interactive walkthroughs to show new users what their first result looks like before they have to produce it.
- Make one walkthrough per first task, not one for the whole product.
- Put them where new users are, which is the welcome email, the empty state and the getting-started docs.
- Watch where viewers drop, and fix that step.
Why Onboarding Is Harder than It Looks
An empty account shows none of the value. The user has to imagine the result while doing setup work.
- Product tours inside the app interrupt the user while they try to work.
- Long getting-started guides are skimmed.
- Video is fixed-pace and quickly stale.
A walkthrough the user opens when they choose, that shows the finished result with sample data, sets the target before the work.
Map the First Tasks
List the tasks a new user must complete before the product is useful. Usually three to five.
| First task | Walkthrough shows |
|---|---|
| Create the first project | Where to click and what a filled project looks like |
| Invite a colleague | The invite path and what the colleague sees |
| Connect a data source | The connection screen and the first imported view |
| Produce the first output | The report, invoice or page the product makes |
Each becomes a short walkthrough.
Place Them Where New Users Are
- Welcome email. Link the first-task walkthrough.
- Empty state. Link the walkthrough that fills that screen.
- Getting-started docs. Embed each walkthrough at the top of its page.
- Follow-up emails. Link the next task when the previous one is done.
Make Them Look Finished
The point is to show the account with data in it. Record in a test account with plausible data, and use replace text and change a number to make the sample look real. Blur anything that is not sample data. See screenshot hygiene.
An Illustrative Worked Example
This example is hypothetical. A project tool sees many signups never create a second project.
- They make three walkthroughs. Create a project, add tasks and invite a teammate.
- Each is four to six steps, recorded in a filled test account.
- The empty projects page links the first one. The welcome email links all three.
- Drop-off shows viewers leave on the "add tasks" step's second screen. They rewrite the callout.
The Old Way Versus a Better Way
| Old way | Better way |
|---|---|
| One long tour of the whole product | One short walkthrough per first task |
| Recorded in an empty account | Recorded in an account with sample data |
| Shown at signup, all at once | Shown where the user is, when they need it |
| Written by the product team only | Reviewed by support, who see where users stall |
| Never updated after launch | Checked when the first-run flow changes |
Sequence the Walkthroughs
New users do tasks in an order. Your walkthroughs should follow it.
- The welcome email links the first task.
- Each walkthrough's end card points at the screen where the user does that task for real.
- The follow-up email for the next task links the next walkthrough.
This keeps each walkthrough short, because it covers only one task, and keeps the user moving from one result to the next.
Ask Support Where Users Stall
Support sees where new users get stuck before anyone else. Ask them which first tasks generate the most questions. Those are the walkthroughs to build first. The same demos can then sit in the help articles for those tasks. See demos in help centers.
A 30-Day Rollout Plan
Week 1. List the first tasks and ask support which ones cause questions.
Week 2. Record a walkthrough for each, in a filled test account.
Week 3. Link them from the welcome email, the empty states and the getting-started docs.
Week 4. Read completion and drop-off, and fix the weakest step in each.
Where Proovyt Fits (Full Disclosure)
Proovyt is an interactive demo tool, and this is our blog.
- Record each task with the Chrome extension and publish a link or embed.
- Zoom a step up to 3x on the hotspot so small controls are clear.
- Creator, Pro and Team show completion and drop-off per step.
Proovyt walkthroughs play as demos on a hosted page or embed. They are not an in-app tour layered on your live product. See the product page and the FAQ.
Common Mistakes
- One long onboarding demo covering everything.
- Recording in an empty account, which shows none of the value.
- Forgetting to update walkthroughs after the first-run flow changes.
- No link back to the real task in the end card.
The Bottom Line
Show new users the finished result before they build it. One short walkthrough per first task, placed where they already are, does more than a long tour.
Frequently Asked Questions
Is this the same as an in-app product tour? No. A walkthrough is a demo the user opens from an email, a doc or an empty state. It does not run over your live app.
How many walkthroughs should onboarding have? One per first task, usually three to five.
Should the end card link into the app? Yes. Point it at the screen where the user does the task for real.
Can a team share the work? On Team, admins invite members, and members can create their own demos when an admin allows it.
Where do help-center demos fit? They cover tasks after onboarding. See demos in help centers.