A Fly On The Wall

Observing Without Interfering: The Fly On The Wall Technique

The fly on the wall technique is exactly what it sounds like. You watch users interact with a product or system without jumping in to help, correct, or guide them. You sit there. You let them struggle if they need to. Most people doing usability sessions get this wrong because they can't stand idly by when someone clicks the wrong button for the third time. I ran a series of usability sessions for a healthcare client last year where we were testing a new patient intake portal. The standard approach would've been to have researchers sit beside participants and prompt them through flows. We did the opposite. One-way mirror, recording software, and four researchers sitting in a dark room taking notes. The participants thought they were being tested alone. The difference in behavior was immediately obvious. When people know someone is watching and waiting to help, they ask for assistance faster and give up quicker. When they think they're alone, they push through confusion longer. That additional struggle time is where you find the actual pain points. Not the quick asks for help that happen when a facilitator is hovering.

Setting Up The Observation

You need three things before you start: a recording setup that captures both screen and facial reaction, a note-taking system that doesn't slow your observers down, and a group of observers who can actually stay quiet. The recording part is straightforward. OBS works fine for internal teams. For clients, I usually send them into Zoom cloud recording with the participant's screen share. The key detail most people miss is making sure your audio picks up the participant's verbal reactions without requiring them to wear headphones. If they need headphones, they can't talk naturally. Note-taking is where things get messy. I use a shared Google Doc with timestamps. Each observer gets their own column. When someone clicks away from the form field to the FAQ link at 4:12, that goes in the doc. When someone re-reads the same sentence three times at 6:33, that goes in too. You're collecting moments of friction, not writing a narrative.

Running The Session

Here's how I structure a typical fly on the wall session: First, give the participant a single task statement. Not a script. Not step-by-step instructions. Something like "You need to schedule a follow-up appointment for next week." That's it. Then you stop talking entirely. Second, do not intervene. At all. If they say "I don't know what to do," you stay silent. If they close the tab, you stay silent. If they take eight minutes to fill out a two-minute form, you stay silent. This is the hard part. My team's first session had someone freeze on a page for twelve minutes because a label was ambiguous. The temptation to jump in and say "just click the blue button" was overwhelming. We didn't. That twelve-minute pause was the most useful data point in the entire study.

Third, after the task is complete, you ask what just happened. Now you get their retrospective feedback. They'll tell you where they got confused, what they assumed, and what felt wrong. This is different from the in-the-moment data. The in-the-moment stuff shows you what they actually do. The retrospective interview shows you what they think they should have done.

A Real Problem I Hit And How I Fixed It

Last year I was running fly on the wall sessions for a financial dashboard. Everything was going fine until I noticed a pattern. Several participants would navigate away from a page, then immediately come back and do the exact same thing they just tried. They weren't stuck. They were second-guessing themselves because they thought the system wasn't registering their input. The issue was that our feedback states were too subtle. A green checkmark appeared for half a second and then disappeared. People missed it. They assumed failure and retried. I spent three days debugging thinking we had a technical problem. Turns out the UI just needed a longer confirmation state. I changed it to a static green banner that stayed for five seconds and the retry behavior dropped by eighty percent. This is the thing about fly on the wall observations. You see behaviors that the participants themselves don't notice. They don't report the double-clicking or the backtracking because it feels normal to them in the moment. That's why you need the recording playback. Watching the raw footage after the session reveals things the observers missed in real time.

Where This Method Falls Apart

The fly on the wall approach doesn't work for everything. If you're testing a workflow that requires training or context, people will flounder for the wrong reasons. You end up with data that looks like a design problem but is actually a knowledge gap. I learned this the hard way during a session for an enterprise inventory system. Users spent twenty minutes trying to understand the navigation structure. Afterward, they admitted they'd never used the system before and had no idea what half the terms meant. That wasn't a UX problem. That was an onboarding problem. We had wasted a session. It also doesn't scale well. Running proper fly on the wall observations requires at least two people per session, plus recording and note-taking infrastructure. You can't just hand this to an intern and walk away. The observers need to know what to look for, or you end up with empty notes and a video file nobody watches. If you need faster feedback and can't invest in the observer bandwidth, consider a think-aloud protocol instead. It's more invasive but it surfaces issues faster. You get less natural behavior, but you get actionable data in half the time. For early-stage prototypes, that tradeoff usually makes sense.

The Counter-Intuitive Part

Most teams think more observers mean better data. That's wrong. After about five observers in a room, you start hearing the same observations repeated. The last two people in the room are mostly just confirming what the first three already found. I usually cap it at three observers max, and I rotate them in and out between sessions so fresh eyes catch things the tired ones miss. Another thing nobody tells you: the best fly on the wall sessions happen when you've already solved the obvious problems. If your prototype has broken links, missing copy, or a workflow that doesn't complete, you're not learning about user behavior. You're just watching people react to a broken product. Fix the basics first, then observe. Otherwise you're optimizing a mess instead of understanding how people actually use your thing. The recordings are useful, but only if someone actually watches them. I've seen teams record dozens of sessions and then never review the footage. The notes capture the what. The video captures the why. A participant's face hitting the desk when they realize they've been on the wrong page for six minutes tells you more than any timestamped note ever could. Budget time for video review in your project plan. It's not optional if you want this method to work.