In-Product AI Interviews

In-product AI interviews let participants talk while they use the product you are testing. UserTold.ai combines live interview segments with silent observation so teams can capture both what users say and what they actually do.

The important distinction is timing: watch behavior before explaining it. A participant's pause, repeated click, navigation loop, or spoken confusion is evidence. UserTold preserves that evidence, then uses a planned debrief to ask why it happened.

The interview modes

UserTold studies are composed from three segment modes:

Mode	What happens	Best use
speak	The AI reads a scripted instruction or transition	Welcome, consent, task setup, closing
observe	The participant uses the product while recording continues	Usability tasks, onboarding, checkout, setup
talk	The AI conducts a voice interview	Discovery questions, debriefs, follow-up probes

A common script is speak -> observe -> talk -> speak. The participant receives clear instructions, completes the task naturally, then answers follow-up questions based on what just happened.

Example study flow

For an activation study, the script might look like this:

{
  "version": 2,
  "goals": [
    { "id": "activate", "description": "Find where new users hesitate before first successful setup." }
  ],
  "segments": [
    {
      "id": "intro",
      "mode": "speak",
      "title": "Introduction",
      "speak_text": "Please set up the product as you normally would. I will stay quiet while you work."
    },
    {
      "id": "setup-task",
      "mode": "observe",
      "title": "Complete setup",
      "instruction": "Connect the required account and reach the setup confirmation screen.",
      "conductor_context": "Expected flow: provider select -> credential entry -> connection test -> confirmation. Watch for repeated docs visits or uncertainty around API key scope.",
      "max_duration_s": 420,
      "advance_when": "url:/setup/complete"
    },
    {
      "id": "debrief",
      "mode": "talk",
      "title": "Debrief",
      "talk": {
        "goals": ["activate"],
        "system_prompt": "Ask about the moments where the participant paused, reopened docs, or changed fields. Ask one question at a time."
      }
    }
  ]
}

The observation segment captures the real workflow. The debrief asks about concrete behavior instead of asking the user to imagine what they might do.

What gets captured

UserTold stores the interview record, transcript, media, page navigation, timeline events, and extracted evidence. The useful output is not just a recording; it is a reviewable evidence package:

• quotes from the participant
• page URL or product area at the moment of friction
• timestamped behavior
• evidence type and confidence
• source interview links

This gives builders enough context to understand the failure without replaying every minute of every interview.

Avoiding biased rescue

During observe, UserTold does not interrupt, coach, or navigate for the participant. That is intentional. If the interviewer rescues the user, the team loses the natural stuck moment.

Use conductor_context to tell the system what "expected" and "stuck" look like, then follow with a talk debrief. The participant can explain what they expected after the behavior has been preserved.

Qualified next step

Use in-product AI interviews when the workflow itself matters. If you only need a conversation, start with studies. If you need to watch onboarding, activation, pricing comprehension, or feature discovery, start from the study design guide and include at least one observe segment.