IT ARTICLES

Web-based applications, like all software systems, are obviously intended for people to use. Not so obvious is that users may not be the single most important factor in the application design equation. This is not an academic argument, particularly for the harried designer or development manager who must decide how and where to spend limited time and other resources. What should be the real focus of your design efforts?


The all-too-easy, politically correct, user-centered answer is that the whole of the user experience needs to be addressed, that the target audience must be understood in all its human richness, and that every aspect of the experience needs to be designed. But a growing number of forward thinkers in the field are recognizing that too much attention on users as people can lead designers to miss the main point, which is not the users themselves, but what they are doing and trying to do in the context of the larger activities in which they are involved. Designing for use rather than for users is a way to focus design more sharply.


Even the inventor of the term user-centered design has shifted gears. In a controversial essay that had the bloggers all a-twitter last year, usability guru Donald Norman argued that human-centered design could be harmful. “Focus upon humans,” he wrote, “detracts from support for the activities themselves.” The result can be cool technology that doesn’t work and complex applications that don’t help people do the stuff they need to do. He called for an activity-centered approach to design that makes the activities within which tools are used the primary concern of designers. By focusing on activities, designers are better able to deliver tools that effectively support users in real-world contexts.



User-centered design is so much the gold-standard approach that it is easy to miss some of the recurring problems with this perspective:

First, an overly purist user-centered, customer-centered approach often contributes to the dreaded disease of creeping featuritis that plagues so much of modern technology. Features are piled on features, with interface controls ending up hung willy-nilly on the interface until almost anything is possible but users can’t figure out how to do it. As Microsoft’s Chris Capossela put it, “When we asked [what users wanted in] Office, nine times out of ten, they named something…already in the product; they just couldn’t find it.” Don Norman expressed the root of the problem this way: “Listening to customers is always wise, but acceding to their requests can lead to overly complex designs....[that become] more complex and less understandable with each revision.”

Secondly, paying too close attention to users and what they say can lead to timid, overly conservative design that does little more than repeat the mistakes of the past in a pretty new package. The users of Web applications, like people everywhere, are often deeply ambivalent about change. On the one hand, they want new and better applications that enable them to do new things. On the other, they don’t want to have to learn anything new. They want the new application to look and work just like the old one that they struggled so long and hard to learn to use. Of course that is also the very application that they constantly kvetch about because it’s so difficult to use.

In truth, users do not always know what will really work for them. First impressions or reactions during usability testing or in feedback sessions may be very different from how people react or perform in real-world activities. Show them almost anything really novel and they’ll wince or get a puzzled look or complain that it doesn’t look like Microsoft Office. On one medical informatics project, every test subject complained about screens being too busy, yet they were able to complete their work faster than ever with fewer mistakes. If designers go back to the drawing board every time a user stumbles or hesitates or flinches, the results are same-old-same-old applications that stick users with so-so tools.

A third problem with users is that there are so many of them. And they are all different. They want different things and like different things and react differently. I have watched teams run in circles as they redesign for each new user who gives them feedback on a paper prototype or each new group passing through the usability lab. The genuine diversity of real people can distract designers from the commonality of their needs and interests.

Robert Hoekman, author of Designing the Obvious: A Common Sense Approach to Web Application Design (New Rider Press, 2006), has a suggestion, one that echoes Donald Norman’s advice: “Ignore the demands of specific audiences and make the product work for anyone by focusing on the activity instead of the user.”

The trick to designing effective support for an activity is to develop a rich picture of what the activity is about, what it involves, and what participants are trying to accomplish. Activity modeling, part of the well-established usage-centered design method, is a simple and systematic way to capture and organize understanding about human activity as it relates to the design of applications and other technology tools. It draws on extensive project experience to zero in on those things about activities that are most likely to be useful in shaping a good design.

The first and most important thing to understand is why people engage in activities. All human activity is purposeful. Understand the purpose and you have a better chance of successfully supporting the activity. Ordinary people do not use an information kiosk in a downtown square because they enjoy poking at moving images on a touch screen. They are engaged in larger activities with a purpose, such as shopping for gifts or trying to organize lunch or seeing the sites. They want to be able to get what they need from the kiosk and get on with more important things. These activities are affected by other activities in which the same participants are engaged as well as by adjoining activities in the same place and time. While shopping for gifts, the group may also be trying to keep the kids entertained. An impromptu performance by a juggler may impinge on using the kiosk.

Real human activities are rather amorphous collections of actions with their own specific goals that are combined in various and changing ways in pursuit of a common purpose. Finding a gift for Aunt Edna may involve exploring stores nearby, reviewing categories of gifts, checking prices or specific brands, and all of these might be undertaken in almost any order or combination. Scripting and lock-step interfaces often run counter to the inherent nature of human activity.

To keep track of all the relevant activities, their purposes, participants, and the artifacts involved, you need a map of some kind. In activity modeling, a Participation Map gives a quick overview of all the players and parts in activities in a way that is easy for both interaction designers and hard-core developers to understand.

Just naming activities and mapping the participation is not enough. All human activity is hierarchical and can be understood at three levels of analysis: activity, action, and operation. An Activity Map represents how various activities fit together and provides a rich picture of their composition in terms of actions and operations.

Consider a technical support application deployed on an intranet to help telephone support staff. The activity of providing telephone technical support is connected with other business activities, and the staff themselves are involved in various activities, such as taking breaks, that are not part of technical support but impinge on it. The focal activity of providing telephone support includes a variety of loosely connected actions related by a common overall purpose. These involve interactions with the support application itself as well as with other support staff and customers. Interactions with the application might include such things as getting the next queued call, getting customer details, or finding a problem description in the knowledge base. External actions involving other participants and artifacts might include greeting the customer, learning about the problem, checking paper documentation, and offering a problem solution. Operations are the individual steps users take to perform actions. To get customer details, for example, the user might need to provide some form of identifying data about the customer, then select from a number of possible matches.

Agile modeling techniques, such as card storming and card clustering, make it possible to quickly construct a rich activity model that inventories and organizes the full range of activities and actions that need to be taken into account in a design. A good application has a visual and interaction design that directly reflects how activities, actions, and operations fit together.

Focusing on activity and use is not a retreat to the bad old days of technology-centered, inside-out design in which developers arrogantly assumed they knew what was best and threw it at users. It is just an easy way to avoid the pitfalls of human-centered design without giving up its advantages. In the final analysis, understanding your users as people is far less important than understanding them as participants in activities. Indeed, the evidence from over a decade of experience with usage-centered design suggests that shifting the focus from users to the activities in which they are engaged leads to better tools--and that means a better user experience and happier users.