An AI Interviewer That Asks About What Users Just Did

UserTold runs AI user interviews inside your product. A participant tries a real task, the interviewer asks about the observed experience in a planned voice debrief, and the resulting Evidence stays connected to the source recording and page context.

Run your first interview · See a debrief · Pricing

See a debrief

Follow one moment

Illustrative walkthrough · no recording or live AI

Preserve what happened

/settings/account → back → /settings/account

The participant returns to account settings. The interviewer stays silent during the task. The path alone does not explain what they expected.

This debrief walkthrough is an illustrative example, not a recording, live AI conversation, or customer result. It shows how an observed moment can lead to a specific follow-up and reviewable evidence.

Task: Find the current plan and where to change it.

Observed: The participant opens account settings, goes back, and opens account settings again. This establishes the path; it does not establish their expectation.

Interviewer: “When you returned to account settings, what were you looking for?”

Participant: “I thought the plan would be under my account. I didn't know it belonged to the workspace.”

Evidence for review: The navigation and the participant's explanation support investigating where plan controls are placed. They do not prove that all users have this problem or that moving the controls is the right fix.

For the broader product flow, watch the research overview.

How the real-time debrief works

  1. Set the research goal. Choose what you need to learn and give the participant a neutral task.
  2. Observe without interruption. With consent and the available permissions, UserTold captures speech, interactions, navigation, and page context while the participant uses the product. Screen recording is available on supported desktop browsers.
  3. Prepare a running evidence summary. When realtime analysis is enabled for the planned debrief, UserTold periodically summarizes recent speech, product behavior, and page changes. It keeps participant reports, recorded behavior, and interpretation distinct.
  4. Ask grounded follow-up questions. The planned voice conversation starts from the latest valid summary and the assigned goals. The interviewer chooses the next question from that context and the participant's answers. If no summary is available, it uses a fallback rather than pretending to know what happened.
  5. Review evidence after the interview. Separate post-interview processing extracts source-linked Evidence. Review the recording and grouped Findings before deciding whether to send anything to a tracker.

Real-time analysis prepares the debrief; it does not interrupt an observation segment to rescue the participant. It is not a claim that the model understands every video frame. The Study Runtime reference explains the handoff and recovery behavior.

What can I learn?

Your questionStart here
Why do new users stop during setup?Investigate onboarding and activation.
What need is behind a feature request?Identify user needs.
Why is choosing a plan difficult?Research your pricing page.
Why do users keep their old workaround?Learn why users switch.

UserTold works with real users your team can already reach. It does not recruit participants or guarantee responses. Use the method-selection guide to decide whether an in-product interview fits your question.

Set up an interview

Create a Project and install its script once across your website. The Project has a starter interview; tailor a Study when you need a specific task, observation, and debrief. Review its goals, flow, Invitation, and Visibility, then test the complete experience yourself before inviting users.

For an observation-based study, configure a task instruction, an Observe segment, and a planned Talk debrief. Enable realtime analysis on that Talk when it should use the preceding activity. Research Script Templates gives you tasks and neutral questions to adapt; Quickstart covers installation and verification.

You can use the dashboard or connect an agent through MCP or the CLI. Linear and GitHub are optional handoff destinations, not prerequisites for running an interview.

Questions before you start

Does it ask everyone the same questions?

The Study sets the research goals and flow. In a Talk segment the interviewer can follow up on the participant's answers and supplied evidence. Scripted introductions and task instructions remain scripted. The contextual debrief is a planned part of the Study, not an automatic reaction to every pause.

What happens without screen sharing?

Screen capture depends on browser support and participant permission. Voice and available product events can still provide context; they are not a substitute for a screen recording you do not have. Review capture availability and never present inferred screen behavior as recorded evidence.

Can users decline recording?

Participants see a recording disclosure and choose whether to start. They can stop the interview. Your invitation should explain the research purpose and voluntary participation. See Participant Consent and Privacy.

What does the team receive?

The captured Interview record, transcript and available behavior context, and Evidence after processing. Related Evidence can support draft Findings. A human or project-aware agent reviews the source and synthesis; review alone does not create an external issue. See how to analyze interviews.

What does it cost?

UserTold charges for recorded interview time. See current pricing for Managed AI and bring-your-own-key options before running a Study.

Run one focused study

Choose the question you need to answer, set up your first interview, and review its source evidence before inviting more participants. Start with one real workflow and follow the explanation through to a decision.