How do you help a new user get something done in your app?
Pick one result they came for, such as saving their first project. Put the action where they can find it, show that it worked, and offer a short hint if the next step is hard to find. A guide can explain the task while the app remains responsible for doing it.
What counts as a useful first result?
A useful result gives the person something they can come back to. In a project app, that could be a saved project with a name. Seeing three tour cards is a guide activity. Seeing the project on a second visit shows the app did the work.
Watch where a new person pauses. If they cannot find New project, improve its label or location first. Add guidance for the context the button alone cannot explain.
When do you need a hint, a checklist or a tour?
Use a hint for one unclear control, a checklist for tasks someone can do over several visits, and a short tour when they need to see where related actions happen. Keep a way to skip or dismiss the help.
A tour should never be the only path to starting work. A returning user, a person who closes the guide, or a customer on a plan whose guide stops displaying still needs the action.
Compare tools
Scroll the table sideways to read every column.
| Tool | What guidance can you add?Start with one real task. | What must your app send?Where the guidance learns who to help. | Who counts toward the bill?The usage unit and what happens at the limit. | What should you test for language and keyboard access?How a person gets help or exits it. | What can you keep if you switch?What to save or export separately. |
|---|---|---|---|---|---|
| Userflow | Flows and checklists that can guide a person to a task or respond to an action. | Load the correct environment token and identify the intended user. | Identified users in a rolling 30-day window, including identified anonymous and staging users. Overages can move you to the next tier. | Check the matching locale and plan limit. Escape closes only on steps with a backdrop. | Export session analytics. Save guide wording and conditions separately. |
| UserGuiding | Guides and hotspots created through a browser extension, plus checklists. | Load its container on selected pages and decide whether to pass a stable user ID. | Unique visitors where the container runs in the last 30 days. Guides stop displaying when the quota is exceeded. | Growth lists localization. Test focus, progression and dismissal in the actual guide. | Export relevant analytics and user attributes. Remove the container when you stop using it. |
| Product Fruits | Tours and hints shown from your workspace, with checklists for several actions. | Pass a stable user identifier and the app’s language for localized content. | Users the integration starts for per monthly billing period, counted separately in each workspace. | Check the language code. Tour and hint cards have no default-language fallback. | Export tracked users and their activity. Keep instructions and targeting rules in your own notes. |
| Appcues | Guides, checklists and announcements tied to product behavior. | Install the web integration and identify users. Send confirmed app actions you need for targeting or measurement. | Identified users in a rolling 30-day window. Check the quote and published-experience limit. | Flows can use translation files. Check focus and dismissal in the actual modal, slideout or tooltip. | Export experience analytics or survey responses. Save guide copy and rules separately. |
| Chameleon | Tours, tooltips and other experiences placed on selected screens. | Connect the browser script and user ID. Select the app domains and audience where the guide can appear. | Distinct IDs tracked over the prior 30 days, including eligible IDs from imports and integrations. | Check the plan’s language allowance and where focus goes when the experience closes. | Export experience events and user properties. Save screen references and targeting rules. |
| Userpilot | Add guides and checklists and measure the outcome through product events. | Install the web integration. Identify the user and send the event for the app action. | People who take a tracked action in a calendar month. Starter lists up to 2,000. | Flow localization is listed from Growth. Verify the keyboard and focus behavior of each step. | Keep guide and translation files separately. Confirm the plan for bulk event or user export. |
| Pendo | Offer an in-app guide to a segment and use analytics to decide who needs it. | Choose visitor identifiers and the metadata needed for targeting. Check analytics collection separately. | Free documents a 500 MAU limit, calculated from unique Visitor IDs in a 30-day period. | Configure applicable accessibility options on each step. Verify focus and keyboard use in the live-shaped test state. | Guide PDF and translation exports cover different needs. Check plan-specific data exports and keep targeting rules. |
| Stonly | Offer different help steps based on an answer the visitor chooses. | Install the widget. Use only the targeting data the guide needs where supported. | Guide views count outside visitors. Post-trial Basic lists 400 monthly views and five published guides. | Check the plan’s languages and how a visitor advances, returns and closes using the keyboard. | Check PDF export entitlement. Keep branch conditions and original guide text separately. |
| Frigade Engage | Show checklists, tours or announcements using Engage flows. | Built-in components use React. No-code publishing uses an integrated channel. Define what completes a step. | Confirm Engage pricing and usage units. The public Assistant figures apply to a separate product. | Check the component, labels, close action and focus return inside your own app. | Keep copy, flow conditions and custom code. Verify account options for moving progress data. |
| Driver.js | Highlight controls and show guidance one step at a time. | Define targets and launch conditions in your own app. | MIT-licensed library. Your team maintains the steps and any storage you add. | Configure labels and controls. Check the actual keyboard and screen-reader path in your app. | Keep tour definitions and copy with the code. Your app owns any progress storage it adds. |
Who should see a first-project guide?
Sketch a new account, a returning account and someone who cannot create projects. Put the guide beside the task for the first account and plan what each of the other two should see. Do this on paper before you connect an app or collect any user information.
- Write the show and stop rulesStart when a new account can create a project and has none. Stop when the app saves a project or the visitor dismisses the guide. Your app still decides who can create projects.
- Trace the keyboard and another languageMark where focus starts, how to close the guide and where focus returns. Read the translated text beside the control it refers to. Check a narrow layout where controls can move.
- Plan a result checkUse the app’s saved-project result to measure success. Track guide views and completions separately so you can tell whether people received help and whether they got the task done.
What should you price and save before turning it on?
Count people who would actually be identified or visit a page with the script, using the vendor’s rules. Some tools count in a rolling 30-day window and others in a billing period. Check whether guest traffic, staging or multiple workspaces can add to the count.
Keep the guide text, translations, screen locations and show/stop conditions in your own files. Export any supported reporting data before removing the script. Confirm users can still finish the task without it.