How to Interview New Users About Onboarding
Run onboarding interviews that uncover new users' goals, setup obstacles, and first useful outcomes with a practical discussion guide and analysis example.
Product walkthrough
The walkthrough shows the board and discussion workflow that can sit alongside your private interview notes.
Watch the product walkthroughSee how findings become shared requests
Practical context for How to Interview New Users About Onboarding
Interview new users about a recent onboarding attempt, starting with the result they wanted and reconstructing what they did. The aim is to understand the task in context: what they brought with them, where they needed help, and whether the result was useful.
Choose a specific uncertainty before recruiting. For example, you might need to learn why new administrators cannot finish their first import. Include people who succeeded, needed help, or stopped. Label the groups in your notes; a few interviews reveal explanations to investigate, not the prevalence of each problem across all customers.
Prepare a short discussion guide
Explain the purpose, who will see the notes, and whether you want to record the session. Confirm the participant is comfortable proceeding. Make clear that the conversation is research and does not affect their access to help. Arrange a separate support follow-up when they need one.
GOV.UK's interview guidance recommends open, neutral prompts and concrete accounts of past experiences. Start with the customer's goal and follow the sequence of their attempt before introducing ideas for improvements. Pilot the guide with a colleague to catch confusing wording.
- +What were you hoping to get done when you first opened [product]?
- +Talk me through the last time you tried to [task].
- +What did you need from another person or system before you could continue?
Follow the moment where progress changed
When someone says setup was confusing, ask what they were looking at and what they expected to happen next. Request an example of the confusing wording, if they remember it. Avoid inserting an explanation such as 'Was the permission screen the problem?' before hearing their account.
If the participant wants to demonstrate the task, use a setup suitable for sharing and keep account secrets off screen. Note when you provide help: a result reached after your instruction is different from an unassisted attempt. An interview reconstructs an experience; a fresh observed attempt provides additional evidence and should be labeled separately.
- +What happened after that, and what did you do next?
- +How did you decide whether the result was ready to use?
- +What did you do instead when you could not continue?
Turn the account into a finding you can check
In a fictional interview, an administrator says they waited for a finance colleague to approve the data source. The observation is a dependency on approval; 'we need a longer product tour' is an untested solution. A useful next step is to investigate how the product explains prerequisites and supports that handoff.
Write a finding with the attempted task, evidence reference, consequence, and unresolved question. Compare it with other sessions and support reports, preserving disagreements. Summarize what you learned at the end of the conversation so the participant can correct your interpretation, and explain how the team will use the research.
- +Evidence: a specific reported sequence or observed action.
- +Interpretation: the explanation the team currently considers plausible.
- +Next check: an observation or question that could confirm or challenge it.
Keep exploring this topic
These next reads help you move from the concept on this page to a framework, tool, template, or deeper comparison you can apply right away.
Questions teams usually ask
How many onboarding interviews do we need?
Recruit to cover the roles, tasks, and outcomes relevant to your question, then review where uncertainty remains. A small qualitative sample does not establish a population-wide completion rate.
Should the interviewer show a proposed redesign?
First understand the recent experience. If you then test a proposal, introduce it as a separate activity and record what the participant does, not only whether they say they like it.
Where should interview notes live?
Keep detailed notes and contact information in your private research workspace. Put a suitable non-sensitive problem summary on a feedback board when it is useful for wider discussion.
Bring research findings into product discussion
Add suitable problem summaries to Feedbackly so your team can discuss requests and keep customers informed as decisions change.