Menu

Beta — We’re reformatting our articles to work with the new site, but this is one hasn’t been done yet; it may contain formatting issues. No need to report this. We’re working on it.

Designing Web Applications for Use

by Larry Constantine
on December 11, 2006

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.

More from Larry Constantine: In Larry’s UIE Virtual Seminar Don’t Panic: Design and Usability Under Pressure, he’ll share a wide range of field-proven tricks and techniques for conquering design and usability problems while in crunch mode.