Shadowing Reveals What Users Actually Do
Shadowing follows users in real tasks to catch where stated behavior diverges from reality. Deploy it when workflows cross tools, rooms, or teams and interviews miss the real friction. Your presence changes behavior; filter genuine habits from performance.
WHY IT EXISTS: People are unreliable reporters of their own habits. When asked, they summarize, idealize, or omit steps that have become automatic through years of repetition. Shadowing was developed to close the gap between what users say they do and what they actually do by placing the researcher inside the context where the work happens. The method treats the environment itself as data, because physical layout, noise, and interruptions shape decisions as much as interface design does.
THE MENTAL MODEL: Think of shadowing as an archaeological dig rather than a survey. You are not collecting opinions; you are excavating behavior. The user is the expert, and you are the apprentice who follows without interfering, building a map of invisible infrastructure such as sticky notes, side conversations, browser tabs, and physical shortcuts that never appear in a process diagram. Your goal is to notice the gaps between official procedure and lived practice.
HOW IT WORKS: A researcher obtains explicit permission and spends a sustained block of time, typically hours rather than minutes, accompanying a participant through their normal tasks. The researcher takes structured notes on actions, environmental cues, errors, workarounds, and emotional reactions, often asking the user to think aloud only after the observation period to avoid polluting the natural flow. Recording is common when consent allows, but the richest insights usually come from the researcher's own real time questions about artifacts and anomalies. The output is a contextual inquiry that captures sequences, artifacts, and pain points in the moment.
WHEN TO USE IT: Shadowing pays off when a workflow is complex, spans many tools, or is deeply habitual. It is essential for redesigning internal enterprise software, clinical workflows, field service tools, or any domain where users have stopped noticing friction because they have built elaborate compensating rituals. It also helps when stakeholders assume a process is linear and you need hard evidence that it is actually chaotic, socially negotiated, or dependent on unofficial tools like spreadsheets and chat messages.
WHEN NOT TO USE IT: Avoid shadowing when the context is highly sensitive, such as private medical consultations, financial audits, or legally protected conversations, because the observer risks violating confidentiality or altering the dynamic beyond what usability research can justify. It is also a poor fit for simple transactional tasks that can be measured faster with analytics, experiments, or unmoderated remote usability sessions where scale matters more than contextual nuance.
ONE CANONICAL EXAMPLE: A hospital wants to improve its electronic health record system. Instead of interviewing nurses, a researcher shadows a nurse through a full twelve hour shift. The researcher discovers that the nurse prints patient labels at a central station because the bedside scanner fails one in five times, then hides the backup labels in a pocket for quick access during emergencies. No interview would have surfaced this workaround because the nurse no longer thinks of it as a problem; it is simply how the job gets done. The insight leads to a hardware fix that cuts charting time far more than any interface tweak could.
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.