Stop Designing for Users

“How often we neglect to address the purposes of those who are in the system and those of the environment.”   —Béla Bánáthy

“No man is an island,

Entire of itself.

Each is a piece of the continent,

 A part of the main.” —John Donne

Design for Activities, Not Individuals

Most products support activities underpinned by collaboration and sharing. Designing for individuals may actually be harmful because these activities reflect ongoing transformations of artifacts, individuals, and social interactions. Focusing on individuals might improve things for one person at the cost of others. As Donald Norman says in Human-Centered Design Considered Harmful:

The more something is tailored for the particular likes, dislikes, skills, and needs of a particular target population, the less likely it will be appropriate for others.

Activity-Centered Design (ACD) focuses on the activity context in which individuals interact with your product. Instead of analyzing specific goals and tasks, ACD focuses on the analysis of meaningful, goal-directed actions supported by tools and artifacts in a social world. The Wikipedia article about Activity Theory says:

The goal of Activity Theory is understanding the mental capabilities of a single individual. However, it rejects the isolated individuals as insufficient unit of analysis, analyzing the cultural and technical aspects of human actions.

Limitations of Personas

Persona documents have become the de facto design artifact for human-centered design. Personas are a proxy for a real customer when teams lack customer participation. Don’t get me wrong, I understand the value of personas as a way to build empathy for customers. A designer will typically create a persona document to bring a human perspective to the conversation. Sometimes, this is a callow reaction to a team overly focused on technical implementation. Most of the time, the persona document contains inert data. Through the process of modeling the ultimate customer, the persona becomes too general to represent any real-life customer.

Personas Increase Risk of Feature Bloat

Many companies boast about their human-centered approach to design and their use of personas, yet they still manage to design complicated products characterized by bloat, infrequent improvements, and a set of features that no single customer fully utilizes. A product team that bootstraps their design process by identifying several individual personas doom themselves to create a bloated product. Obliged to partition the solution across a set of features for each persona, this approach results in an incoherent product difficult for people to adopt and use in their daily lives.

I believe persona documents emerge for several common reasons:

• The customer is missing or does not actually exist
• A preference for analyzing personas through the myopia of roles, job titles, and demographics
• Unreasonable paranoia about engineers making decisions without empathy for customers

I am not saying that personas are “bad” and that we should ignore decades of progress in human-centered design thinking. On the contrary, I believe products which metastasize with limited focus on real human needs can improve with human-centered methods like persona documents.

Activity Systems: Participants and Activities

An activity system is a community of people interacting with each other through tools and artifacts in the social world. As Béla Bánáthy says in Characteristics of A Human Activity System:

Purpose, process, interaction, integration, and emergence are salient markers of understanding … we should think about and define human activity systems always at three levels: (1) A system serves the purpose of its collective entity. (2) It serves the purpose of its members. (3) It serves its environment of the larger system in which it is embedded.

The people in the system are affected by being in the system, and by their participation in the system they affect the system. People in the system select and carry out activities—individually and collectively—that will enable them to attain a collectively identified purpose.

The process by which these relationships are maintained is the system’s regulation—the rules of the game—and the limits within which these rules can be sustained are the conditions of the systems stability through time. It is here where commitment (to shared purpose) and motivation (to carry out activities) play such an important role.

People are affected by their participation in the activity system, and through their participation they affect the activity system.

Instead of analyzing individuals as personas, you can analyze from an activity perspective using a human activity diagram. I typically create a human activity diagram in collaboration with my team so we can quickly develop a shared understanding of the new activity context we are working in. The diagram’s simplicity makes it easy to share, redraw on a whiteboard, and easily transform as you learn more about the activity. Professor Yrjö Engeström from the University of Helsinki in Finland invented the human activity system diagram to facilitate his own research into organizational and workplace learning.

Human Activity Diagram

I recommend redrawing this diagram and filling it in with an activity context familiar to you. Then, try filling in another one with an activity context less familiar to you. Many questions will arrive in your head as you try to fill it in. Your questions will become hypotheses to validate by talking with people and immersing yourself in their activity context.

From left to right the eight categories are:

• Participants: Actors engaging in the activity
• Rules and Rituals: Conventions and guidelines regulating the activity
• Community: Social context shared by all participants engaging in the activity
• Activity: Any purposeful human endeavor
• Tools and Artifacts: The means for the accumulation and transmission of social knowledge in the activity
• Division of Labor: Social strata and hierarchical structure of the activity
• Objective: A shared goal obtained through the interaction between participants, tools, and artifacts within the context of the activity
• Outcomes: The participant’s motivations for obtaining the objective

Casual Carpool - Human Activity Diagram

As a resident of Berkeley and an employee at a company based in the financial district of San Francisco, I am very familiar with the activity of casual carpool. As a new casual carpooler, I started brainstorming ideas for a product to solve two problems I observed: A long queue of passengers, and a long queue of drivers at peak times (from 8 – 9:00 AM). I assumed an imbalance in either queue was an indication of impeded flow: A problem to fix. I immediately envisioned app ideas that I was certain no one would willingly adopt; certainly not in the morning and not when they’re in a hurry to get to work.

Instead of wasting my time throwing a solution at the problem, I opted to improve my understanding of the activity by looking at the casual carpool as an activity system. As I observed the rules and rituals of casual carpooling and the behavior patterns that the participants displayed, I realized that the queues actually worked fine. Any imbalance between the flow of the passenger queue and the driver queue were fleeting; average wait times were well under 10 minutes.

By analyzing the whole system, rather than individuals, I came to the realization that the objective for drivers and passengers to carpool with minimal coordination was already happening. In the casual carpool pickup spots rituals and norms naturally emerge with readily available tools and artifacts. Namely, vehicles and queues. What about other issues like lost-and-found items? The system has already compensated: If someone forgets to take a purse or a phone when they get out of a vehicle, the driver can simply post “found” signs at the head of the passenger queue. Any other solution I can think of would require another layer of coordination between drivers and passengers.

Casual Carpool represents an emergent system influenced by external forces such as state laws and our disdain for congestion on roadways. Any solution in the form of a tool like an iPhone app or even a human agent like a “Carpool Coordinator” would undermine the overall objective of “carpool with minimal coordination”.

In the next example you will see how you can use a human activity diagram to generate an entirely new tool in an emerging activity system context.

What are we making?

At Thoughtworks, I work with teams who create products used in software development environments. I often help these teams develop narratives that frame product decisions from a customer perspective. In order to develop these narratives, the depth of understanding of the human activity context must be deep, and the customer’s language common to the team.

One of these teams, Luau, provide a measurable way for customers to improve their software development processes through evidence-based experimentation. In the past, when I would ask the team “Why is your product important?” I got slightly different answers from each of them. The common term they would use was “cycle time”. Cycle time is the measure of the amount of time it takes for an idea to go from doing to done. The team was certain cycle time was important to their customers, and it was their job to make a tool to convince customers it was the right measure for process improvement.

The team had to figure out how they would present cycle time to their customers, and how their customers would define their workflows. The Luau team also had to figure out a solution which would integrate with their customer’s daily lives. To help them discover possible solutions I used Engeström’s human activity diagram. I introduced the diagram in a workshop setting and encouraged them to try to answer the following questions:

• What is the activity that your product will support?
• Who are the participants in the activity?
• What objectives do participants achieve through this activity?
• What are the tools and artifacts these participants already use in their daily lives that are relevant to this activity?
• What are the outcomes of this activity?

The product team members had about five minutes to fill in Engeström’s diagram. Then, they each took turns presenting their diagram and receiving feedback from each other about their assumptions. Within the first thirty minutes of the workshop, I witnessed a common language develop about the activity their cycle time product would support. In turn, a new set of hypotheses formed that they could go out and validate.

You can see the result of the workshop in the diagram below. They actually displayed it in their team space and referred to it whenever they were vetting ideas for features or formulating questions they would ask during interviews with customers.

Software Process Improvement - Human Activity Diagram

What are they making now? A product that helps teams continuously improve by providing visibility into the health of the team. Using indicators like cycle time, the product helps teams identify work that is slow, stuck, or churning, and potential bottlenecks in the workflow. Their customers already rely on information radiators for continuous visibility into the health of their projects, so the product team’s product works as an information radiator. The product “radiates” in a team room on a LCD display, providing customers with the ability to drill down and see which of their work items are slow, stuck, churning, or a potential bottleneck.

As an aside, the team found that the activity diagram and the business model canvas converged in interesting ways. As they performed customer development activities, they kept the “Software Process Improvement” activity diagram in the back of their mind. The activity informed the top-level goal for their product (help customers who want to continuously improve) while the business model canvas reflected how they would garner customer attention, acquire customers, and retain customers for their solution.

Can you think of other examples about how activity systems have affected product decisions?

Further Reading

Donald Norman shares his thoughts about Activity-Centered Design in these articles:

• Logic Versus Usage: The Case for Activity-Centered Design
• Human-Centered Design Considered Harmful
• HCD harmful? A Clarification

Also, anthropology professor Bonnie Nardi has written a book called Acting with Technology that explores activity theory as a framework for interaction design. Bonnie and Donald were once colleagues at Apple.