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

Home > Articles > Design > Voices That Matter

Web Design Reference Guide

Hosted by

Redefining User-Centered Design, Part 3

Last updated Oct 17, 2003.

In part 1 of this three-part series, I discussed the problems with user-centered design (UCD) and told you that I’d show you how to solve those problems by modifying your approach. In part 2, I explained the central ideas of my approach, activity-centered design (ACD) and behavior-centered design (BCD).

Now, finally, I’ll tell you how I’ve synthesized these ideas into a fast, effective, repeatable process that produces great results and works in half the time (typically) of user-centered design.

Activity- and Behavior-Centered Design (ABCD)

For fairly obvious reasons, the name for my approach is activity- and behavior-centered design (ABCD). And no, I didn’t plan this name based on the rather catchy abbreviation—it just worked out that way.

As you might guess, ABCD is a combination of the ACD and BCD approaches:

  • ACD represents the process of achieving good design.
  • BCD represents the design itself
  • ABCD forms a complete picture of design.

The ABCD process breaks down into a few basic steps:

  1. Study and document the activity that the application is meant to support.
  2. Begin the interface designs, implementing constant improvements to make the designs as usable as they can be, and thoroughly documenting each interaction as you go.
  3. Once the application has been launched, start listening for trends in the feedback that comes from customers.

ABCD is the approach we use most often at Miskeeto. It saves our clients quite a bit of money and time because our design process takes less time than a traditional UCD process and produces high-quality results that dramatically reduce customer support costs and design changes.

I’ve also used ABCD in previous internal positions, including one in which I established and ran a User Experience team for a software company that had been driven entirely by software engineers. Because ABCD is often a quick process, my design team worked on the same iteration schedule as that of the Agile development teams, and got great results. Once, in fact, we used ABCD to design three brand-new applications at the same time, in roughly four weeks. Months after the releases, the only customer support calls that came in were related to bugs; none were related to the interface or confusion about how to complete tasks. With ABCD, I was able to shift the developer-centric company so that it now includes a design team and process that fits the company’s Agile development model.

Step 1: Study and Document the Activity

Let’s talk about studying and documenting the activity. Once you know what problem you’re trying to solve, your goal is to become a subject matter expert (SME) on the activity that the application is meant to support. You become a subject matter expert by performing the activity yourself in a number of ways, by talking to existing experts, and/or by watching people perform the activity in everyday life.

In many cases, you can gather a significant amount of information simply by performing the activity yourself. This method also takes the least amount of time.

If you need to talk to people who know more about the activity than you do, that process takes a little more time, but you usually won’t need more than a few people to tell you how the activity is performed. Your goal isn’t to understand the life goals of your users, demographics, or anything else—only how they perform the activity in question. While talking to these experts, focus on trends in the activity itself, not the idiosyncrasies of the people performing it. In doing so, you’ll spend a lot less time than you would in doing user research in a traditional UCD process.

Once you understand the activity, you can document it in what I call an activity grid, which is just a fancy term for an outline—like the ones used to write term papers.

As I discussed in part 2, there are exactly four levels in the activity hierarchy:

  • Activity
  • Tasks
  • Actions
  • Operations

Each of these levels needs to be addressed in the activity grid, but you’ll be amazed at how easy it is to do. An activity grid for a simple audio player, for example, might look like Figure 1.

Figure 1

Figure 1 A basic activity grid for an audio application.

The grid starts with a summary of the activity to be performed, and is followed by three hierarchical levels that represent tasks, actions, and then operations.

The great thing about activity grids is that they’re actionable:

  • Use the activity grid as a guideline for what needs to be designed.
  • Reference the activity grid continually to make sure that you’re building the right things—and that any "wrong" things are being excluded.

You can also hand the activity grid to a CEO without fear, because the result is just a simple list of things that the application needs to do. Same for developers. And when you start hearing arguments for adding features that don’t directly contribute to the activity, you can point to the activity grid as a reason to say no.

Interestingly, the details that are added at the operations layer of the grid quite literally become a set of instructions for what you need to put onto each screen. If an operation entails clicking a Save Changes button to save some profile settings, for example, you know you need a Save Changes button at the last step of the Edit Profile interaction.

That’s it. That’s the whole ACD process. Study the activity in whatever way you can, and create an activity grid.

I don’t mean to imply that you can create the whole grid at once, but very often you’ll be able to write the Activity and Tasks levels in an afternoon, the Actions level quickly thereafter as ideas get fleshed out a bit more, and the Operations level within a few days of starting your research and sketching out initial design ideas. Of course, for simpler applications, sometimes you can create it all at once. I’ve created many activity grids in just a couple of hours.

Step 2: Design and Document

Once the activity grid is ironed out, you can start the design work. Often, you can even start designing the basic layout and flow of an application while creating the activity grid.

Regardless, the key to success at this point is to document each interaction thoroughly as you go along. This documentation is crucial to ensuring that every detail of the application has been considered. Why? Because the process of documenting your designs forces you to think about every step of every interaction. In doing this, you’ll easily uncover mistakes in the design, see opportunities for improvement, and so on.

The most effective method I’ve used so far is to document as I design. For example, I’ll create either a set of wireframes or a storyboard for a single interaction, and then I’ll write detailed, step-by-step use cases for the interaction that explain these steps to the person who will be writing the code. While doing this, I notice all sorts of things that can be improved, and I can fix them then and there. Perhaps I forgot a link in one of the screens. Maybe a label is unclear. Or I might realize that in order to complete a certain task, an operation I had completely forgotten needs to be created to make that task possible. Whatever the case, the simple act of writing down each step brings to light all sorts of things that can be fixed now rather than later.

Generally, I use wireframes or low-resolution composites for designing interactions. Occasionally, I create simple prototypes by using either Adobe Flash or OmniGraffle (Mac only, but you Windows geeks can use Microsoft Visio). I also frequently record protocasts (screencast versions of prototypes), just to further ensure that developers and such will understand how something needs to work.

Regardless of which design tool I use, I create a design description document (DDD), in which I write the aforementioned use cases. A design description document is basically a slide deck created in Apple Keynote or Microsoft PowerPoint, and containing wireframes or comps, detailed use cases for all the interactions that can be performed on each screen, and any relevant notes.

Each slide contains one wireframe or storyboard, and the sidebar lists the steps for all the interactions that can occur. These slides also include exceptions to the use cases—for example, what happens when a user leaves a required form field blank.

I also create a wireframe for each possible state of a screen, showing details such as the following:

  • Default state of the page
  • How errors will be displayed
  • How changes to the page should look (such as with single-screen interactions based on AJAX or DHTML)

To learn a lot more about DDDs and to download templates for Microsoft PowerPoint and Apple Keynote, visit my Design Description Documents page.

There’s a question I haven’t answered yet, though: How do you get a firm understanding of how people use computers and the Web, so you can design things that will make sense to them? There are many ways to do this, most of which are very cheap and can be done in your spare time. Here’s a wildly incomplete list:

  • Watch people using the public-access computers at the library. It’s far better to watch people working in real-world situations than in contrived environments such as a usability testing session. Don’t turn into a stalker or anything; just casually keep an eye on how people deal with screens and interact with them.
  • Read reports from usability studies done by leading experts such as Jared Spool at User Interface Engineering, Jakob Nielsen’s Alertbox, or the Nielsen Norman Group.
  • Check out blogs, books, whatever—anything you can find.
  • Watch friends and family members.
  • Perform five-second usability tests in the hallway where you work. Show someone a screen for five seconds and then ask him or her to recall either what was on the page or how to begin a specific interaction.
  • Pay attention during conversations with people you know as they talk about things that bother them, things they love, or things they don’t understand as they work on the Web. Make notes.
  • Read books about how to achieve good design, such as Jakob Nielsen and Marie Tahir’s Homepage Usability: 50 Websites Deconstructed; Steve Krug’s Don’t Make Me Think: A Common Sense Approach to Web Usability, and my own Designing the Obvious: A Common Sense Approach to Web Application Design.

Unfortunately, it’s impossible to go into depth on this subject within this little article, but this list should help you get started. But I can tell you this: The real key is to pay attention to trends in human-computer interaction, and not the idiosyncrasies of individuals you will inevitably hear about if you do user interviews in a UCD process. By noticing trends, you’ll learn boatloads of principles that will help you to design interactions that make sense to users.

Not by coincidence, one of the best ways to learn about human behavior is the last step in the ABCD approach.

Step 3: Plug In and Start Listening

Web designers have an advantage that few designers in other disciplines can boast: the ability to make constant updates at almost no cost. Keep site metrics on everything you put out; then study those metrics, and modify your designs based on them. Tools such as Google Analytics and CrazyEgg are fantastic for accruing these metrics, and there’s something about site metrics that makes them undeniably reliable. Simply put: Numbers don’t lie.

You can track click paths, which links were clicked on a page, where people abandoned the site, how they got there in the first place, and a ton of other things, all useful information for determining how well your design works and how it might be improved.

You can also survey your customers using SurveyMonkey.com, creating customer feedback forms for your applications and review the customers’ comments.

That said, be sure to watch for trends in how people work with your application—and not to the idiosyncrasies of your most vocal users. I can’t stress this principle enough. The largest part of your audience is composed of people who are intermediate-level users of the application, regardless of how much expertise they might have on the activity that the application is designed to support. The people who actively complain or cheer about you on a daily basis are not representative of the biggest part of your audience.

I’ve just told you to listen to and respect the expert users in your audience. But you should take everything they say with a big grain of salt. If you do everything they want to you to do to "improve" the application, you’ll end up with something that’s unmanageable for intermediate users.

Most of all, keep in mind that user complaints and requests are indications of symptoms of problems, but not actual problems. When they say that they want you to do something specific to improve the application, figure out what the underlying problem really is and solve that problem instead. For example, if several users say that they’d like a menu added to access functionality already available elsewhere in the application, perhaps the real problem is the organization of the application, or the labels used to identify the features, not a missing menu.

Finally, you can do what’s known as eating your own dog food. That is, use the applications that you create. Use them as religiously as your most devoted users. By doing this, you’ll find the problems and learn how to fix them.

Moving Forward with a New Solution

In this series, we’ve looked at the problems with user-centered design, explored how activity- and behavior-centered design can help solve many of these problems, and seen how paying attention to real human behavior and documenting design as you go along can help you to create usable designs right out of the gate.

By studying activities rather than specific user types, you spend significantly less time on design research, and you come out the other side with more meaningful deliverables—activity grids, design description documents, and so on— that can help you start creating a great application immediately. (Incidentally, these deliverables help you to communicate your research and design ideas to managers, developers, QA teams, and even documentation teams effectively.)

With a faster, leaner process, it’s much easier to do quality design work within the constraints of an Agile development process. As such, you’re armed with an approach that makes you part of the team instead of someone who never quite fits into it.

Activity- and behavior-centered design is a fast, effective, and repeatable approach that produces great results in much less time than traditional user-centered design. If you decide to test it out, this information should help you to get started.

If you run into problems or have questions, please feel free to contact me via my web site. I’m happy to help. Otherwise, keep an eye on my blog for ongoing information and ideas about application design.

Best of luck!