The session that fell apart (and why I'm glad it did)

The plan was immaculate. Seven tasks, forty-five minutes, a prototype I'd walked through twice, and a participant who'd confirmed twice that yes, they were ready and yes, the link worked.

Three minutes in, the prototype crashed. Not gracefully — a hard white screen, the kind that makes a participant apologise for something that isn't their fault.

I had two choices. I could rescue the session, apologise, and fight the tech while the clock ran down. Or I could do what I ended up doing: tell the truth, stop pretending we were testing anything, and have a conversation instead.

What happened next

We never finished the tasks. We did something more useful. Freed from the script, the participant talked about the last time they'd tried to do this real task on a real website — what they clicked, where they got stuck, what made them give up and call the company instead.

That conversation produced three findings that the tidy task list never would have surfaced. All three were about trust and error recovery, which turned out to be the actual design problem.

What I changed after that

• I tell participants upfront that technology breaks and it's never their fault — before anything breaks.
• I keep a short list of "off-script" questions for exactly this moment: What would you do next in real life? When did you last try this for real?
• I stopped treating a derailed session as a failed one. Sometimes the participant is telling you something more important than the task list.

The awkward truth

The sessions that look smoothest on a recording are often the least informative. A session that falls apart — if you handle it honestly — is a session where the participant stops performing and starts telling the truth. The polish isn't the point. The participant is.