Publishers of technology books, eBooks, and videos for creative people

Home > Articles > Web Design & Development > Usability

Web Design Reference Guide

Hosted by

Redefining User-Centered Design, Part 2

Last updated Oct 17, 2003.

By Robert Hoekman, Jr.

In Part 1 of this three-part article I talked about some of the flaws of a traditional User-Centered Design (UCD) process. Here, we'll take a look at a solution to some of these problems, and see examples of products designed without the aid of UCD.

The Two Faces of Design

Although many designers rely on process alone, there are, in reality, two aspects to design.

The first is, of course, process, which is how we arrive at the solutions we create. The second is the design itself—the part of the solution that the customer actually touches and with which he interacts.

UCD addresses only the process. It doesn't tell us how to achieve a usable interface. But a process, no matter how effective or time-tested it may be, doesn't automatically result in a usable or desirable product. And if your product is usable and desirable, it doesn't matter one bit which process you used to get there, as long as you can repeat it.

Hence, in addition to looking at how to improve the speed and quality of the processes that lead us to the solution, it's also vitally important to look at the solution itself.

First, let's look at a few ways to solve some of the problems of UCD with a process that is fast, effective, and capable of fitting into real-world development cycles. After that, we'll take a look at the design of the interfaces themselves.

Activity Centered Design

Donald Norman, author of The Design of Everyday Things and Jakob Nielsen's partner at the Nielsen/Norman Group, released an article in June 2005 titled, "Human-Centered Design Considered Harmful." In the article, Norman discussed the idea of Activity Centered Design, which, despite being an old idea, has yet to be thoroughly explored in the software world.

Like UCD, Activity Centered Design (ACD) is a process. Unlike UCD, however, ACD focuses not on the least stable part of the design equation—the user—but rather on the activity an application is meant to support.

This distinction may seem subtle—after all, studying an activity can mean studying the people that perform it—but it's actually pretty dramatic. It means that, in many cases, a product can be scoped, designed, documented, built, and released to wild success without researching a single end-user.

How is this possible? To answer this, let's take a look at the building blocks of ACD.

First, ACD is based on activity theory, which basically asserts that an activity occurs whenever a person interacts with an object for some particular reason (e.g. A person who is hungry performs the activity of eating by grabbing a cheeseburger.) The advantage of studying an activity instead of a user is that activities, unlike our highly unreliable users, are in many cases quite stable.

Users can pull us in several different directions, constantly contradict each other's demands and so-called needs, and struggle to get their goals addressed in an application. When studying activities, however, this problem largely disappears.

This is so because activities break down into simple, manageable parts that can be studied, learned, and understood without a lot of effort. These parts are as follows:

Activities

Tasks

Actions

Operations

To put this in context:

At the highest level is an activity, such as sharing photographs.

Each activity breaks down into a series of tasks (whether required or optional). The activity of sharing photographs is completed by performing the tasks of organizing photos, naming and renaming them, creating and editing captions, adding and removing photos, creating a list of people with which to share the photos, and of course, sharing them.

Tasks are completed through actions. The task of naming a photo, for example, is achieved through the actions of choosing a photo, entering a name, and saving the name.

Finally, each action is comprised of individual operations. The action of choosing a photo, for example, is completed through the rather simple operation of clicking a photo from a gallery page.

Because each activity an application needs to support can be broken down in this way, devising a feature set for an application can be a very quick process. Granted, not all activities are as simple as that of sharing photographs, and some require more in-depth research, but in most cases, becoming somewhat of an expert on an activity takes significantly less time than the activity of researching users, one of the central tenets of User-Centered Design. (I'll discuss the process of researching activities more in Part 3.)

And since activities are relatively stable compared to the people who perform them, the information acquired through this process is far more reliable.

Also, through this process, it's very easy to determine what features need to be designed and built for an application, because you end up with a comprehensive list of things that need to be done to perform the activity.

It also becomes easy to determine what should not be designed or built. With a very concise list of actions and operations to be performed, anything that doesn't directly contribute to completing the activity can be justifiably thrown out. There's no need to argue about whether or not "Sarah the Amateur Photographer" or "Billy the Teenager with a Digital Camera" can handle the feature or will desire it, because, well, it doesn't matter. Regardless of who the user is, the activity is performed by completing the tasks associated with it.

So, in addition to being fast, ACD means you can stop having daily arguments with people about what should or should not be included in the application. Everyone has the same list and can easily see for themselves when something does or doesn't contribute to an activity.

Has This Been Done Before?

Yes. In fact, you probably own a few products that were designed without the aid of user research, and instead were designed to support an activity.

The iPod, for example, is a shining example of something that succeeded in spite of what users thought or said they wanted. My favorite quote from one unnamed user: "The Reality Distiortion Field™ is starting to warp Steve’s mind if he thinks for one second that this thing is gonna take off."

When it was originally announced, the iPod got a really poor reception by people on several Mac fan sites. Members didn't believe they would buy an MP3 player for $400 because they already had ones from other companies that cost far less money and had more features.

I'm betting most of those users now own iPods.

If Apple had asked its audience what it wanted instead of plowing ahead with its own plans, we could all be using Zunes right now. (Of course, the Zune might never have been developed without the need to compete with the iPod.)

As Donald Norman points out in his controversial article, many products were designed without the aid of a UCD process, including "[...] kitchen utensils, garden tools, woodworking tools, typewriters, cameras, and sporting equipment [...]". People in different cultures, of different ages, and of different skills and mental abilities have all been able to learn to use these tools. If they had been designed for a specific type of user, this may not have been true.

The automobile, in fact, was designed without user research. It was designed to support a specific activity and, through iteration, eventually went from emulating horse-drawn carriages to something much more.

Because activities can be studied quickly and produce more reliable information than from user research, many of the problems of UCD are magically erased. The difficulty of adapting to an Agile development process, incorporating personas and scenarios into the design process, selling personas to code-minded developers and results-oriented managers—all of these problems disappear when you change your focus to activities instead of users.

And since activities can be performed similarly by people in a range of cultures, roles, and contexts, we're also able to design things through ACD that work well for a variety of users instead of a narrow set of defined user types. We find ourselves in a position where we can welcome the unexpected user type instead of alienating him.

Google, as I mentioned in Part 1 of this article, was designed to facilitate searching. And, as we all know, it does that very well. If it had been designed for a small set of user types, there's no telling how that magical white home page would look.

Finally, because the scope of an activity is decently finite, we can easily justify the addition and exclusion of features based on the framework of the activity. So once the product is released in the wild and we start getting feedback from users, we can more easily weed out which feature requests can and should be ignored.

The golden rule? If it doesn't support the activity, it's out.

Behavior Centered Design

Once we've sorted out the activity an application is meant to support, it's time to pay attention to the design of the interface itself. To do this, we move on to Behavior Centered Design (BCD).

Essentially, BCD is simply the act of designing interactions that make sense to people.

This is done by applying good design principles, making use of design patterns, challenging and improving upon standards, and learning as much as you can about how people actually work with computers.

It's done by applying best practices, such as keeping columns of text down to roughly 12 words so users aren't forced to move their heads while reading, which decreases retention, and designing pages to support the natural direction in which audiences will read them (i.e. Westerners scan designs naturally from top-left to bottom-right, so a page that flows in this direction is generally perceived as well-designed). It's also done by designing each and every state of each and every interaction on purpose instead of leaving these decisions in the hands of fate, or worse, a developer!

There are two parts to BCD. The first part is research. The second part is thorough design documentation.

The research is for learning to understand human behavior. It means being one part usability specialist, one part psychologist.

The second part—thorough design documentation—is about spelling out the details of the interactions we design rather than simply laying out a screen and leaving it at that.

I often see designs from consulting firms and internal teams where a designer has gone through much trouble to create a pixel-perfect wireframe or comp, but has entirely neglected to make any notes about how the design is supposed to behave. And the behavior of an interactive system is the most important part!

When this happens, the developers who will eventually build the product are left with a choice. They can either:

Go back to the designer and ask lots of questions about how an interaction is supposed to work OR

Plow ahead and decide for themselves how the interaction should behave

Neither option is good. The first leads to interruptions to other work and wasted time. The second leads to application behaviors that the designer didn't necessarily intend.

To avoid this, and to create interactions that work exactly the way they should, we need to design and document every detail of an application, or we'll end up with subpar results and users that are less satisfied than they could have been.

In Part 3, I'll talk about what to focus on in your research and where to find good information, as well as how to document your designs to get the best results.

Finally, I'll discuss how I've synthesized the notions of Activity Centered Design and Behavior Centered Design to create the fast, effective, and repeatable process we use at Miskeeto to produce great results in half the time of UCD.