Onboarding Usability Test Script for SaaS

Analytics can show the step where users leave. Session replay can show what happened on screen. Neither reliably explains what the user expected at the moment they got stuck. UserTold observes a real task, asks about that moment, and returns source-linked evidence for review before work is created.

Start with the unanswered question

Onboarding and activation problems often look obvious in a funnel but remain hard to explain:

• a new user reaches setup but never completes it
• a trial user visits the same page twice and leaves
• a buyer compares plans without choosing one
• an administrator opens documentation during an integration and does not return
• a user reaches a blank state instead of first value

The useful question is not only where did they leave? It is what were they trying to do, what did they expect, and what happened instead?

Design an onboarding usability test

Choose one activation outcome: create a usable project, connect an integration, or complete a first meaningful task. Ask users who recently attempted that workflow to participate. Do not assume that everyone who abandoned it had a usability problem; some may lack time, permission, or a reason to continue.

A task for a collaboration product is:

Set up a workspace for your next project. Stop when you believe it is ready to use. You do not need to invite anyone or make a purchase for this research.

Adapt the task to what the participant can safely do. In UserTold, create an Observe segment followed by a planned Talk debrief, set the relevant page Visibility, and review the recording disclosure. Enable Pre-debrief analysis for the debrief so its questions can use the preceding activity.

Copy the complete onboarding test script

This script tests whether a new user can create a usable project without requiring payment or real teammate invitations.

{
  "version": 2,
  "goals": [
    {
      "id": "onboarding",
      "description": "Find what prevents a new user from creating a usable first project."
    }
  ],
  "segments": [
    {
      "id": "instructions",
      "mode": "speak",
      "title": "Instructions",
      "speak_text": "Please create a project for your next piece of work. Stop before inviting teammates or making a payment. I will stay quiet while you try it; choose Done when you finish or want to stop."
    },
    {
      "id": "use-product",
      "mode": "observe",
      "title": "Try the onboarding task",
      "instruction": "Create a project for your next piece of work. Stop before inviting teammates or making a payment.",
      "conductor_context": "This product calls a shared workspace a project. Preserve uncertainty about the project name, setup choices, and access settings without assuming any of them caused a problem.",
      "max_duration_s": 300
    },
    {
      "id": "debrief",
      "mode": "talk",
      "title": "Ask about the task",
      "talk": {
        "research_mode": "usability_debrief",
        "goals": ["onboarding"],
        "system_prompt": "Use the captured task context to ask about specific pauses, errors, or backtracking. Ask what the participant was looking for and what they expected. If a moment is not supported by the context, ask them to describe what happened instead of inventing a click or problem. Ask one question at a time; do not suggest fixes."
      },
      "experimental_capabilities": {
        "realtime_analysis": true
      }
    },
    {
      "id": "thanks",
      "mode": "speak",
      "title": "Thanks",
      "speak_text": "Thanks for trying the task and sharing what happened."
    }
  ]
}

Ask your agent to adapt it

Adapt the onboarding usability test at https://usertold.ai/guides/find-where-users-get-stuck to my product.

Ask me for one first-value outcome, the safe starting page, what the participant must not change or purchase, and who recently attempted onboarding. Keep the task outcome-based and avoid naming the correct controls. Show the complete Study JSON and wait for approval before saving or activating anything.

Ask about the moment, not your theory

After observation, investigate the source of hesitation without teaching the intended interface:

• What were you trying to finish at that point?
• What did you expect the next step to do?
• What information did you need before continuing?
• What made you decide to stop or go back?
• What would you normally do next outside this session?

Reference a specific pause or return only when it was captured. “You opened settings again; what were you looking for?” is a follow-up to an observation. “Why was our setup confusing?” supplies a conclusion before the participant answers.

For help choosing between analytics, replay, and an interview, use when in-product interviews fit.

A source-linked evidence chain

Keep the task, observed behavior, debrief, conclusion, and resulting Finding connected:

1. Task: Find billing and review the current plan.
2. Observed behavior: The participant opens account settings, returns to the previous page twice, then finds billing under workspace settings.
3. Debrief: The participant explains that billing was expected under account settings.
4. Source-linked conclusion: The observed navigation and explanation point to a narrow information-architecture problem for review.
5. Draft Finding: Participants expect billing controls near account settings and backtrack when they are absent.

This is stronger than “billing is confusing” because a reviewer can inspect the task, route, behavior, explanation, and uncertainty before reviewing the Finding.

Review before changing onboarding

Open the recording and source moments behind a draft Finding. Check successful attempts too: did users with different roles, permissions, or prior experience interpret the same step differently? Narrow the Finding to the conditions the record supports.

For example, if one participant says an optional invitation appeared required, inspect that screen and ask whether other users made the same interpretation. Test clearer optional-step wording before assuming onboarding needs fewer steps. Keep this as a hypothesis until the sources and product state support it.

After a change, repeat the task and review whether the original obstacle still appears. Compare activation metrics separately; a qualitative interview cannot establish conversion lift. Interview analysis explains source review and counter-evidence.

Run one focused study

Keep the task neutral and the sequence short:

1. speak: Explain the task and recording.
2. observe: Stay quiet while the participant uses the product.
3. talk: Ask about the pauses, retries, or unexpected path that just occurred.
4. speak: Close the session.

Read when in-product interviews fit if you are choosing a research method, or browse the other User Interview Script Templates. When evidence is ready for a decision, continue to Prioritize Fixes With Evidence.

Sign in and choose New study, or read the Quickstart first.