Activity Theory as a Design Tool: Analysing Systems Before, During, and After Their Introduction

UsingUsing the activity system as a method for understanding the work a system changes, and the tensions it creates

Requirements documents usually begin with the software. They list features, screens, data entities, and the users who will click on them. Activity Theory begins elsewhere. It asks what collective activity a system is meant to serve, who takes part in that activity and in what roles, what they are working on, what tools and rules shape their actions, and how all of this came to be the way it is. The software then appears as one more element in an existing configuration of work, one that the system will change.see also frame analysis for mapping work contexts

This page sets out Activity Theory as a practical method for three jobs. The first is examining an existing system. The second is diagnosing a system under development. The third is reasoning about how a proposed system will reorganise the activity around it. The social science lecture in this series treats the codebase as a social artefact, and this page takes the next step, from describing the team to designing with the activity in view.

1. Software as a Mediating Artefact FoundationalKnowledge that endures for decades — core principles

Engeström'sEngeström's activity system has six elements: a subject, an object, mediating artefacts, rules, a community, and a division of labour[1]. Kuutti's account of activity theory as a framework for research in human-computer interaction is one place to see how these elements were first applied to technology[4]. The subject works on the object, which is the material or concern that the activity transforms. Mediating artefacts stand between subject and object, and they include tools, language, and procedures. Rules, community, and division of labour describe the social setting in which the work happens.

A software system is usually introduced as the product of an activity: someone designed and built it. The organising claim of this page is that a system does not stop being relevant once it is delivered. Once introduced, it becomes a mediating artefact inside the activity it was built for. It redistributes action, knowledge, discretion, visibility, and responsibility. A timetabling system changes who can see a room's availability, who must ask for a change, and who is answerable when a class is double-booked, whatever its designers intended.the artefact carries frames of its own

That gives the analysis a temporal structure, with four phases.

The last row matters most in practice. A system can remain technically sound while ceasing to support the activity well, because the surrounding work has changed. The code passes its tests, and the people using it have quietly built a set of workarounds around it.

2. Beyond the Checklist Applied / MethodologicalKnowledge with a 5–10 year half-life — stable practice

AA shallow use of Activity Theory fills in six boxes and declares the analysis complete. The boxes contain a list of users, a list of tools, a list of rules, and an organisational chart. Such a list is accurate as far as it goes, and it says little about how the activity works. The method earns its keep when the analyst asks how the elements relate.the glue matters more than the bricks

The aim is to understand how the whole configuration produces particular behaviour and outcomes. Taking each element separately cannot show that.

3. Three Activity Systems Applied / MethodologicalKnowledge with a 5–10 year half-life — stable practice

DiscussionsDiscussions of software often treat "the activity" as one thing. A useful analysis separates at least three activity systems, because each has its own object and its own rules.

The development activity transforms requirements, needs, or opportunities into a working system. Its subjects include developers, designers, product owners, testers, security specialists, operations staff, and maintainers. Its mediating artefacts include programming languages, issue trackers, architecture diagrams, build and deployment pipelines, coding assistants, test suites, and pull requests.

The operational or user activity is the work the software mediates, and it has its own object. The software is one of the means by which users pursue that object. In a university, for example, the object might be supporting student learning. The subject might be a lecturer, an administrator, a student, or a programme team, and the software mediates their work without defining it. Users rarely treat "use the system" as their object. They are trying to teach, learn, diagnose, coordinate, decide, account for something, or care for someone, and the system is one of the things they use to do it.the tool is not the goal it is a means to an end

The maintenance and governance activity keeps the system available, safe, legitimate, and adaptable after it is deployed. Its members may include maintainers, service owners, procurement staff, information security, legal and compliance teams, data-protection specialists, senior management, and external vendors. Its object may be continuity, compliance, risk control, cost, or organisational capability. These objects can conflict with the object of the operational activity.

Most significant software problems involve several of these systems at once. The table below sets out some of the objects a single system may serve in a university setting.

A difficulty of this kind is often not a defect inside any one of these activities. It appears at their boundaries. A deployment gate that looks obstructive to developers may be a necessary control for operations. A mandatory field that looks pointless to users may exist to satisfy a reporting obligation. A compliance rule may also have been turned into a much stricter software constraint than the law requires. Activity Theory helps the analyst ask whether the participants are working on the same object, on compatible objects, or on objects that only appear compatible at a high level of description.

4. The Object Applied / MethodologicalKnowledge with a 5–10 year half-life — stable practice

TheThe object is the easiest element to misread. It is not a target, a deliverable, or a project objective. It is the problem-space, concern, or material that the activity transforms, and it gives the activity its direction. A single system can mediate several objects, each understood differently by the people who use it.

The ticket is therefore not a neutral record of work. It is what Star and Griesemer called a boundary object: an artefact that several communities share and coordinate around while interpreting it in different ways[2]. This explains why apparently minor fields, status labels, dashboards, and workflow rules often become sites of conflict. A status such as "resolved" means one thing to the developer who fixed the code, another to the support worker who has yet to confirm the fix, and a third to the manager counting closed tickets.boundary object: shared but interpreted differently

5. Contradictions and Breakdown Applied / MethodologicalKnowledge with a 5–10 year half-life — stable practice

AA static diagram of an activity system is less useful than the tensions it contains. Engeström's later work treats contradictions as the driving force of change in an activity, and it treats activity systems as multi-voiced and historically produced[3]. In practice, the analyst looks for tensions that recur and that produce many local problems, not for every inconvenience.

The four levels below are a working scheme for this page. They are not a published taxonomy.

The term should be kept for recurring, structural tensions. Four related terms help keep it precise.

• Error: a specific incorrect action.
• Breakdown: a moment when normal work stops running smoothly.
• Conflict: a disagreement that participants express.
• Contradiction: a deeper, systemic tension that can produce repeated errors, breakdowns, and conflicts.

Workarounds deserve particular attention. A spreadsheet kept beside the official system, a standing email thread, or a paper note on a monitor is evidence that the official mediation does not support the activity. Treating a workaround as user disobedience hides that evidence. Treating it as information about the system's fit with the work usually reveals more.workarounds are data, not defiance

6. Studying an Existing System Applied / MethodologicalKnowledge with a 5–10 year half-life — stable practice

TheThe following steps apply the method to a system that is already in use. They are ordered for analysis, though in practice the steps overlap and the analyst will return to earlier ones.

1. Identify the activity, not the application. Start with the question of what meaningful activity the software is meant to mediate. Do not begin with its screens, features, or database tables.
2. Identify subjects and standpoint. Ask from whose standpoint the activity is being described, who performs the visible work, who performs the invisible repair work, who is affected without being treated as a subject, and whose account of the object dominates. Different standpoints can produce different activity maps, and each may be accurate for its own participants.
3. Establish the object and the outcomes. Distinguish the official object, the object inferred from actual practice, the outcome that management measures, and the outcome that users value. These often do not line up.
4. Inventory the mediating artefacts. Include more than the principal application: spreadsheets, email, messaging channels, paper notes, scripts, AI assistants, shared vocabulary, templates, unofficial databases, and the expertise held by particular people.
5. Compare the rules. Separate legal and regulatory obligations, organisational policy, professional norms, team conventions, validation in the interface, constraints enforced by the software, and informal exceptions. Ask when a guideline became a compulsory software rule, and who authorised that translation.
6. Map the community. Include the indirect participants: downstream users, data subjects, support staff, administrators, suppliers, auditors, regulators, and people the system excludes.
7. Map the division of labour. Analyse action and accountability together. Who enters the data, who corrects it, who benefits from it, and who bears the cost of poor data? Who may approve exceptions, and who is blamed when the process fails? Who understands the whole process? Which work is automated, and whose work remains?
8. Collect disturbances. Look for duplicate entry, repeated overrides, unofficial spreadsheets, queues, abandoned fields, recurring support tickets, misread statuses, manual reconciliation, security exceptions, inaccessible screens, and side channels of communication. These are not merely usability defects. They are often evidence of contradictions elsewhere in the system.
9. Trace the history. Ask what process preceded the system, which old rules persist, which workaround has become normal practice, which restructuring changed who owns what, and which original assumptions no longer hold. The history of a repository is one source of this evidence. Policy changes, training material, and user adaptations are others.
10. Model the interacting systems separately. Do not force development, use, governance, and maintenance into one diagram. Model each, then identify the boundary objects and the tensions between them.

7. Using the Method During Development Applied / MethodologicalKnowledge with a 5–10 year half-life — stable practice

ActivityActivity Theory is useful before a system exists as well as after. It can be used to examine assumptions about who the user is, whose problem is being solved, whether stakeholders share an object, which work is currently invisible, and where responsibility now sits.

During requirements work, each proposed requirement can be tested against a short set of questions.

During prototyping, the test should go beyond whether participants can operate the interface. The useful observations concern changes to the sequence of work, premature decisions the prototype forces, useful ambiguity it removes, information it exposes to new parties, data-entry labour it transfers, additional checking it creates, exceptions it makes harder, and changes to who can authorise an action.

During evaluation, outcomes should be assessed at the level of the activity. Did the work become safer? Did the object become easier to pursue? Was labour reduced, or only moved? Did coordination improve? Did professional judgement receive better support? Did the system create new contradictions? Were its benefits and burdens distributed fairly? Usage counts and satisfaction scores answer some of these questions and miss the others.labour moved, not lost: watch the handoffs

8. Power, Visibility, and Division of Labour Applied / MethodologicalKnowledge with a 5–10 year half-life — stable practice

RulesRules and divisions of labour are not neutral descriptions. They record decisions about who may act, who must wait, who may see what, who must supply evidence, who can make exceptions, whose categories become official, whose work becomes measurable, and whose account of success counts.

A system can strengthen some participants while weakening others. It can turn professional judgement into a fixed workflow, or let one community's metrics govern another community's work. This connects to the account of interfaces as incentive structures in the social science lecture. The people who understand a constraint are not always the people with the standing to enforce it, and software can settle that question silently.the system's hidden politics

9. Worked Example: AI-Assisted Code Review Applied / MethodologicalKnowledge with a 5–10 year half-life — stable practice

ConsiderConsider a team that introduces an AI agent to comment on every pull request. The example is chosen because it touches most of the method at once, and because it is a change that many teams are making now.

The intended benefits are a more consistent first pass over each change, earlier detection of common defects, broader security prompts, faster feedback, and another perspective in the review. The question for the analyst is what the agent does to the existing activity.

Evaluation should ask whether human review has become more effective or only shorter. It should ask which classes of issue are now more likely to be found and which are more likely to be missed. It should ask whether reviewers investigate the agent's claims or accept them without checking. It should ask whether knowledge is being distributed or concentrated, who remains accountable for what is merged, and whether novices still have chances to practise reviewing. Finally, it should ask whether the team could continue safely if the service disappeared.

10. AI as Mediating Participant and Artefact Applied / MethodologicalKnowledge with a 5–10 year half-life — stable practice

AnAn AI component can occupy several positions in an activity system. It may be a tool that a developer uses, a partner in an iterative design dialogue, a means of carrying out triage that people once did, a source of rules when its scores determine which changes need review, or the object of an activity, as when a team develops or governs an AI service.

It is tempting to treat the AI as equivalent to a human subject. The more useful move is to ask what happens when work that looks cognitive is transferred to an artefact whose operation may be opaque and whose provider belongs to another activity system. Several questions follow from this. Whose labour is displaced or made invisible? Who checks the AI's advice, and who answers for its consequences? Does it widen professional judgement or narrow it? Does conversational use help participants build understanding, or does automation remove the practice that independent verification depends on? And when an AI provides "another pair of eyes", is that evidence from a genuinely different perspective, or a repetition of patterns from similar training data?

The last question matters for the many-eyes argument that runs through this part of the series. Review by several people is valuable partly because their experience differs. An AI reviewer adds value only to the extent that its suggestions are independent of the author's assumptions. A reviewer that reproduces the author's habits adds volume without adding a new perspective.

Practical Exercise: Map, Disturb, and Redesign Applied / MethodologicalKnowledge with a 5–10 year half-life — stable practice

PartPart A: Map it. Build separate activity-system maps for the principal user activity, for the people who maintain or govern the system, and for one neighbouring activity that the system affects. For each, record the subject, object, mediating artefacts, rules, community, division of labour, and the intended and actual outcomes.

Part B: Find disturbances. Collect at least five examples of workarounds, delays, duplicate work, exceptions, disputes, abandoned features, unofficial tools, or recurring errors. Do not assume that the location of a symptom is the location of its cause.

Part C: Diagnose contradictions. For each disturbance, give the immediate explanation, the structural contradiction that may lie behind it, the historical condition that produced it, and the other activity systems involved.

Part D: Propose a redesign. Design one change to the system, and predict whose work becomes easier, whose becomes harder, which rule changes, which knowledge becomes visible or invisible, how responsibility moves, and what new contradiction might emerge.

Part E: Evaluate the intervention. State what evidence would show that the activity had improved. Do not rely on usage, throughput, or satisfaction alone.

Cautions Applied / MethodologicalKnowledge with a 5–10 year half-life — stable practice

ActivityActivity Theory is an interpretive framework, not a predictive law. Its maps are constructed from particular standpoints, and participants' accounts must be kept distinct from the analyst's interpretation. Technical artefacts are socially situated, but that does not make their technical properties unreal. Collaboration is not automatically good: communities contain unequal authority, and a system can give some participants a voice at the expense of others. The framework is most useful when its contradictions are grounded in observed disturbances, and when it is used to ask better questions rather than to produce a tidy diagram.

Conclusion FoundationalKnowledge that endures for decades — core principles

ActivityActivity Theory changes the question. Instead of asking whether the software implements its requirements, it asks what form of collective activity the software makes possible, which tensions it reorganises, and who gains or loses the capacity to act.

Related Topics

• Software Engineering as Social Science — the social reading of codebases, which this page extends from description to design.
• Software Engineering as Systemic Anatomy & Pathology — diagnosing failures whose symptoms appear far from their causes.
• Generative AI in the Curriculum: Delegation, Collaboration, and Educational Purpose — the educational side of the AI questions raised in section 10.
• Renting or Owning: Cloud Dependence, Retention, and Capability — the dependence and exit questions that the maintenance and governance activity must answer.

References

1. Y. Engeström, Learning by Expanding: An Activity-Theoretical Approach to Developmental Research, Orienta-Konsultit, Helsinki, 1987.
2. S. L. Star and J. R. Griesemer, "Institutional Ecology, 'Translations' and Boundary Objects: Amateurs and Professionals in Berkeley's Museum of Vertebrate Zoology, 1907–39," Social Studies of Science, 19(3), 1989, pp. 387–420. https://doi.org/10.1177/030631289019003001
3. Y. Engeström, "Expansive Learning at Work: Toward an Activity Theoretical Reconceptualization," Journal of Education and Work, 14(1), 2001, pp. 133–156.
4. B. A. Nardi (ed.), Context and Consciousness: Activity Theory and Human-Computer Interaction, MIT Press, 1996. Includes K. Kuutti, "Activity Theory as a Potential Framework for Human-Computer Interaction Research."