Unmoderated screen recordings capture procedure, not motive

What it is

The core deliverable of an unmoderated platform is screen video, click paths, and timestamps. That material is process evidence: where the cursor went, how long a screen was held, which submit failed. It is not evidence of motive. Watching someone open Help and close it does not license the sentence “they did not know the next step”; they may have been checking a risk, hiding the screen from a colleague, or tapping by accident. Process can support what was done and in what order. It cannot, by itself, support why. Treating the recording as an inner monologue is a misuse of the evidence type.

Why it happens

A screen reflects operations that already became public, plus the interface state then visible. Goal, misread, never-seen, and seen-but-rejected can look identical in pixels: linger near a control, then leave. Tools also usually discard the body and the room, leaving the window. Viewers are under narrative pressure and fill the causal chain with their own product knowledge, rewriting “did not tap the primary button” as “could not find the primary button.” Once that fill-in is in the finding, later discussion treats it as observed fact. Process data are dense; motive data are empty on the same timeline; empty slots attract inference.

Studying it

Have several coders first write causes from process alone, then compare those causes with in-the-moment or immediately prompted goal statements, scoring agreement and how often the motive attribution is overturned. Split codes into process descriptions (dwell, backtrack, repeat submit) and motive explanations (did not see, did not understand, did not trust), and count how many “findings” only have the first kind of evidence. Training clips should include matched processes with different reasons, to penalize reading intent off a trajectory.

Where it stops holding

For a short blockage with almost one legal reading—an unresponsive control, a dead-end loop—process is enough for a product conclusion; motive need not be forced. For risk tradeoffs, concealment in a social setting, or several plausible goals, process evidence is weakest. Reasons written later are a different material: not a recording of the original motive, and not garbage just because they are after the fact. Mark them as retrospective statements and place them beside the process. Legal or security audit sometimes needs the trail alone; that is a different question from a usability explanation.

Applying it

• Split every finding into process (an action you can point to on the video) and motive (an explanation that needs extra evidence). Publish the first without the second when the second is missing.
• Ban standalone “the user wanted…” / “the user thought…” sentences; rewrite as “at t seconds opened X then closed it, never entered Y.”
• When motive is required, insert an immediate probe after the critical action or run a live session; do not invent it on replay.
• In review, replay the three findings that most sound like “cause already known.” If the picture only supports process, demote the claim to process level.

Related

• Same group: Q2.16.1 Remote moderated sessions save travel but drop body cues · Q2.16.2 Unmoderated tests allow self-scheduling but block follow-up probes · Q2.16.3 Network and device differences inject product-irrelevant noise
• Adjacent: Q2.01 User interviews · Q1.10 Three-dimensional classification of research methods
• Search terms: process evidence · screen recording · behavior versus motive