What Happens Between the Clicks

Chapter 2 Episode 5

Before you propose a system, design an interface, or plan an intervention, you need to understand how the people you are trying to help actually work today. This sounds obvious, and almost every student I have talked to believes they already do it, but the gap between “I have a general sense of the domain” and “I can describe the workflow, name the stakeholders involved at each step, identify where breakdowns occur, and explain which activities are interrelated” is enormous. Many students cannot clearly articulate this, even after their paper has been accepted. Why is understanding users’ workflow so important? Because it lays a foundation that every design decision, every study variable, and every contribution can be traced back to it.

What Understanding the Workflow Actually Means

Understanding the workflow means much more than just knowing what the user’s task is. A task for clinicians might be “diagnose a patient,” but the workflow that supports this task involves gathering information from multiple systems, consulting with nurses who triaged the patient, reviewing lab results that arrive asynchronously, reconciling conflicting data points, communicating a plan to the care team, and documenting the decision for the next shift, … Each of these steps involves different stakeholders, different tools, different information needs, and different failure modes, and the challenges you identify as research problems are embedded within this complicated network of interdependent activities.

If you focus only on one step (say, presenting AI-generated risk scores to the clinician) without understanding the surrounding workflow, you risk designing something that only solves a narrow problem while creating a lot more new ones upstream or downstream. For instance, the risk score may be accurate, but if the nurse who triages the patient has no visibility into how the score was computed or what data it used, the handoff between nurse and clinician introduces a new gap that your design did not account for. The workflow is where the real constraints, the real dependencies, and the real opportunities for your research live, and understanding it comprehensively is what separates a contribution that holds up in practice from one that only works in isolation.

Activity Theory

If you are looking for a structured way to do this decomposition, Activity Theory offers a framework that I find particularly useful and that has deep roots in HCI research. The theory originated from Soviet psychology through the work of Lev Vygotsky and was developed further by Alexei Leontiev, who introduced the hierarchical structure of activity, action, and operation that I will describe below. Bonnie Nardi and Susanne Bødker were among the researchers who brought Activity Theory into HCI and interaction design in the 1990s, and their core argument was that understanding technology use requires studying the full context of purposeful human work, including the tools, the social structures, and the rules that shape how work gets done. The emphasis on full context makes Activity Theory especially relevant for grounding your research into users’ workflow as an entire activity system.

Activity Theory breaks work down into three levels. At the top level is the activity, which is the high-level goal driving the work. In the aforementioned clinical example, the activity is diagnosing a patient. Below that are actions, which are the specific goal-directed steps that serve the activity. For the diagnosing clinician, actions include reviewing lab results, consulting with the triage nurse, reconciling conflicting data points, and communicating a plan to the care team. At the bottom are operations, which are the concrete, often routine procedures through which each action gets carried out, such as navigating the EHR interface to pull up a specific lab panel or entering a note into the patient record.

The reason this hierarchy matters for your research is that the challenges and design opportunities you are looking for exist at different levels. A problem at the activity level, where clinicians lack the information they need to diagnose accurately, calls for a fundamentally different intervention than a problem at the action level, where lab results and nursing notes live in separate systems and cannot be viewed together, or a problem at the operation level, where the interface requires seven clicks to reach the relevant screen. Knowing where the research question falls in the whole activity hierarchy prevents you from designing a solution at the wrong granularity or from lacking critical context.

Activity Theory also maps the full context surrounding the work through what is often called the activity triangle: the person doing the work, the tools they use, the rules and norms that shape how the work gets done, the community of people involved, and how labor is divided among them. When you study a workflow through this lens, you naturally identify the stakeholders that Q2 asked about, because the framework forces you to account for everyone involved in the system. More importantly, the tensions and contradictions between these components are often where the most productive research problems live, for instance, when the tools available to the clinician do not support the actual coordination practices the team relies on, or when the division of labor creates information gaps that no one in the system has visibility into.

In practice, you can use Activity Theory in your research by mapping the activity system for your target context: identify who is doing the work, what tools they use, what rules constrain them, who else is involved, and how responsibilities are divided. Then look for the tensions, where the tools fail the task, where rules conflict with practice, or where the division of labor creates gaps. These tensions point you toward research problems that are grounded in the real structure of the work, and the decomposition into activity, action, and operation tells you at what level of granularity your intervention should aim.

Two Paths to the Evidence

If researchers have already conducted interviews, observational studies, or workplace visits in which they observed and interviewed stakeholders as they carried out their actual work, those papers are a rich source of empirically grounded evidence. They describe how people actually work, what challenges they encounter, and what needs they articulate in their own words. Your job is to read those studies carefully using the methods from the earlier chapters, identify the workflow they describe, map where challenges arise, understand which activities are affected, and use that understanding as the foundation for your own research questions, your study design, and your approach.

If that qualitative work does not exist for your specific context, that gap itself is an opportunity. You can conduct an initial study focused on understanding user needs and challenges firsthand, through interviews and observations with real stakeholders, before any design work begins. The findings from that study become the evidentiary foundation for everything you want to build, and in many cases, a well-executed study of this kind is a publishable contribution on its own.

Never Rely on Assumptions from Designers

I want to be direct about why this matters enough to get its own post. The needs and challenges that drive your work should be spoken by actual stakeholders, grounded in empirical data, and not imagined by the designers. When a research motivation is built on assumptions about what users need or how they work, every decision downstream inherits those assumptions, and if any of them turn out to be wrong, the study design, the system design, and the findings all carry that error.

I have seen projects where the team designed a tool based on what they believed clinicians needed, only to discover during evaluation that the actual workflow did not match their assumptions, and the tool solved a problem that did not exist in the form they imagined. Such failure happens every single day in industry as well, which I am not going to discuss in much detail here. The time and effort spent building and evaluating that tool could have been saved by spending a few weeks understanding the workflow first. “Slow is smooth, smooth is fast” applies here as much as it did in the earlier post on research question iteration.

Where This Connects to the Motivation Chain

Understanding the workflow feeds directly into Q1 through Q4 of the motivation chain. Q1 (what is the problem) becomes sharper when you can locate the problem within a specific step of a specific workflow. Q2 (who cares) becomes comprehensive when you can name every stakeholder involved in that workflow and explain what is at stake for each of them. Q3 (what have others done) becomes grounded when you can evaluate prior work against the actual workflow and identify where their assumptions diverged from practice. Q4 (your approach) becomes credible when it directly addresses a workflow challenge that real stakeholders identified, because the approach is responding to evidence and not to a hypothesis.