People Use Tools Inside Activity Systems, Not in a Vacuum

Two hospitals adopt the same electronic health record system. One sees improved care coordination and clinician satisfaction after eighteen months. The other sees burnout, workaround behavior, and eventually a partial rollback. The technology is identical. The vendor is identical. The implementation budget was comparable. The standard explanation involves change management, training quality, or physician resistance. Activity theory would say: look at the activity systems, because those are completely different.

Engestrom's (1987) activity system is not a complicated idea, but it is a demanding one. The unit of analysis is not the user, not the tool, and not the task. It is the activity system, which is structured around six interacting elements: a subject (the person or group acting), an object (the motive and goal of the activity), a tool (the mediating artifact), rules (norms and conventions that shape how activity proceeds), a community (the collective the subject belongs to), and a division of labor (how tasks and responsibilities are distributed across community members). These six elements are not independent. They interact, and the interactions generate contradictions, which Engestrom treats not as problems to be avoided but as the engine of development and change.

The roots of activity theory run through Vygotsky and Leontiev. Leontiev's hierarchy of activity, action, and operation is central to understanding why tool use is so hard to generalize across contexts. An activity is the long-term, motive-driven engagement: improving patient outcomes. An action is the goal-directed step within that activity: entering medication data during a patient encounter. An operation is the automatized, habitual execution of an action that requires little conscious attention: typing into a familiar interface. The same physical behavior, typing medication data into an EHR field, is operating at completely different levels of the hierarchy depending on the subject's skill, the tool's familiarity, and the workflow context. A clinician for whom the EHR interface is a transparent operation can attend to the patient while entering data. A clinician for whom the interface is still an effortful action is attending to the screen instead.

This is why training time predicts short-term usability metrics and says nothing useful about whether the tool is actually improving the activity it was supposed to support.

The theories.html comparison matrix I studied has a line that captures activity theory's mechanism cleanly: "mediation and contradictions reveal where design should change work activity." Both halves of that sentence matter. Mediation is the basic idea from Vygotsky: tools do not just support activity, they shape it. A pen shapes how you think through writing differently than a keyboard does. An EHR shapes how a clinician constructs a patient encounter differently than paper charts did. The artifact mediates the relationship between the subject and the object of the activity. Contradictions are disturbances in the activity system when one element is in tension with another. A new EHR introduces documentation requirements that conflict with existing rules about how clinician time is allocated. That is a contradiction between tool and rules. A division of labor that assigns data entry to nursing staff conflicts with an EHR designed around physician encounter documentation. That is a contradiction between tool and division of labor. These contradictions are not user errors. They are structural tensions in the activity system.

The project management tool case is exactly parallel. Asana or Jira or whatever the platform, deployed in one team that has explicit norms about task ownership and tight division of labor, works very differently than the same tool deployed in a team with fluid responsibility and informal coordination. The tool is the same. The community, rules, and division of labor are different. The activity system is different. The outcomes are different. Treating this as a "user adoption problem" misses the structural diagnosis that activity theory provides.

I find activity theory underrated in IS research for the reason the theories.html matrix identified as its limitation: it can become too complex if every element of the activity system is included without focus. That complexity can feel unwieldy if you approach it as a theory that requires all six elements to be treated equally in every study. But that is not how it works in practice. Good activity-theory IS research identifies which elements are in contradiction, which elements are driving the most significant mediation effects, and uses that focus to generate testable propositions or to guide design intervention. The complexity is an invitation to specify, not an obstacle to analysis.

The connection to what I see in organizations is very concrete. When a firm deploys a new tool and the outcome differs from expectations, the typical response is to audit the tool: was the feature set right, was the interface usable, was the data quality sufficient. Activity theory redirects the audit toward the system: what community norms does the tool assume that do not match the actual community? What rules is the tool encoding through its workflow design that conflict with existing organizational rules? What division of labor does the tool's information architecture imply, and how does that differ from the actual division of labor in practice? These questions are harder to answer than a usability survey. They are also far more likely to surface the actual cause of the problem.

This connects to the artifact question I explored in why the IT artifact cannot be treated as a simple given in IS research. The artifact is not neutral. Its design encodes assumptions about what activity it supports, what users know, what rules govern their work, and how labor is divided. When those assumptions do not match the activity system into which the artifact is deployed, the contradiction is not the user's problem to solve. It is a design problem that was invisible until it hit the actual context.

And this is the parallel to structuration theory that I think makes both frameworks stronger when you read them together, which I wrote about in how the same tool produces different outcomes through structuration dynamics. Orlikowski's technology-in-practice captures the recursive shaping between artifact use and organizational practice. Activity theory captures the structural elements of the work system that make some practices possible and others contradictory. They are not the same theory. They illuminate adjacent facets of why tools behave differently in different organizational contexts.

Engestrom's activity system does not let you ask a simple question about a tool. It forces you to specify the entire system in which the tool operates. That is the discipline. That is also why it is the most honest framework for explaining why the same EHR fails in one hospital and succeeds in another.