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 1

Last updated Oct 17, 2003.

By Robert Hoekman, Jr.

Somewhere out there is a company that uses a strict, traditional, user-centered design (UCD) process. It works something like this:

First, a business analyst or interaction designer defines a problem that needs solving. Then, he determines who the audience might be for the solution, locates and interviews people who represent the target audience, and develops a small set of personas (write-ups about archetypal users, usually complete with photos, names, and an overview of the users’ goals). He uses these personas to construct scenarios (hypothetical use cases in which these personas interact with the product in various ways) and eventually starts the design work.

From what I can tell, however, the company that is truly able to adhere to this process exists somewhere in a mythical land with an enormous castle on a hill and a beautiful princess in need of rescue. Yet, somehow, many designers and management teams believe that these elements of user-centered design will earn them superior products and ever-elusive customer loyalty.

This process—and others like it—may make consultants a whole lot of money, but within a corporation struggling to create decent web applications, desktop products, and services for customers, it’s unrealistic at best and ridiculous at worst. In fact, no company I’ve worked for, or with, has been able to stick to a user-centered design process, for a myriad reasons.

As such, the point I’m going to argue in this three-part article is this:

User-centered design is broken, and should be thrown out.

In addition, I’ll show you how I’ve gotten around UCD’s shortcomings with an approach that I’ve used on many projects and which has proven extremely effective and efficient. So effective and efficient, in fact, that I continue to use it in my company, Miskeeto, and it continually saves my clients money.

The Problems With User-Centered Design

Before we look at solutions, however, it’s important to understand the problems.

First, UCD takes a lot of time. User research, user interviews, persona and scenario creation, etc., all take time that most internal design teams simply don’t have the luxury of spending.

Jared Spool of User Interface Engineering, in fact, recently held a virtual seminar titled, "Building Robust Personas in 30 Days or Less." While this was intended as good news to the design world, the in-house design teams I’ve worked with would cringe at the idea of spending 30 days of a design schedule to perform user research and produce what are essentially throwaway deliverables.

Why? Because most design projects don’t have 30-day timelines in total, let alone 30 days to burn prior to doing any actual design work.

In an Agile development environment, for example, designers simply don’t get that kind of lead time. While many designers have struggled over the years to adapt UCD to work within an Agile situation, unsurprisingly, this war has been, for the most part, lost. Sure, a few battles have been won by a few people here and there, but in the larger community, UCD has not found a home in the Agile world.

Most companies—Agile or otherwise—operate under skin-tight deadlines, low budgets, and a serious lack of resources. All of these things detract from the time available to perform user interviews and develop personas.

But there are other problems with UCD that are not strictly related to time or resources.

People Are Strange

For instance, UCD is supposed to help us figure out how people will use our products, but we often end up realizing that no one uses our software the way we intended. Often, they use the tools we provide in ways we never expected (for example, when someone uses a wiki as a project management tool).

Second, the goal of this research is to determine what kinds of features and functionality users need to complete a specific activity. But to perform the research, UCD tells us to focus on the least reliable part of the equation: the user.

Consider the average usability testing session, for example. You bring a person into a lab of some kind, ask her to perform a variety of tasks in an application, and in addition to measuring her success with these interactions, you ask her to rate the difficulty of performing them on a scale from, say, 1 to 5, where "1" is extremely easy and "5" is extremely difficult. And despite watching her struggle for several minutes to complete a particular task, when she eventually figures it out and is asked to rate it, she gives it a "2."

In other words, she rates the interaction based on how difficult she believed it was after she figured out how to complete it, forgetting completely about all the difficulty of figuring it out in the first place. What should have been a "5" goes down in the books as a "2." Meanwhile, another user completes the same task in 10 seconds flat, and rates it a "4" because he guessed and had no real confidence in what he was doing. The interaction didn’t actually make sense to him despite his ability to complete it.

People are remarkably inconsistent. What one person thinks is easy, another thinks is a struggle. Kathy Sierra (of the legendary "Creating Passionate Users" blog) once said, "The more successful the product or service is, the stronger the pressure to give in to user requests. The more users you have, the more diverse the requests. One user’s must-have-or-else feature is another user’s deal-killer." Yet there we are, studying users as a source for reliable answers that are supposed to help us determine what to build.

The Web is Wide Open

Next, UCD tries to narrow the audience we design for down to two or three major user types, but this model comes from more traditional desktop software design, where customers spend a large chunk of money on something, making it rather easy to see what types of people use the product. The model runs into all sorts of problems on the web.

Simply put, if it’s on the web, it can be used by almost anyone with an Internet connection. Without the price barrier, the cost of becoming a user of a particular application is extremely low, making it accessible to a significantly wider audience than we see with desktop applications.

Do you think Google’s home page was designed for a specific set of user types? How about Amazon?

And, when we design for specific user types, what happens to the user types we didn’t expect and therefore didn’t research? Do we want to shut them out? How do we design for a small set of personas and still accommodate the unexpected user?

Consider this description, for example:

"Daniel is a 52-year-old stock broker looking for ways to secure his family’s financial future should something happen to him. He has a high-stress job and, as he ages, he grows more and more concerned about the risk of heart attack and other health ailments.

"He comes to Acme Insurance’s website to explore life insurance options, long-term care options, and Medicare supplements.

"He is prepared to do a good amount of research to make sure he chooses the right solutions, and he wants to know that Acme Insurance will provide every last ounce of information available on these subjects so he can make an informed choice."

Compare that to this description of Greg.

"Greg is an ’accidental entrepreneur.’ He was hacking around with some web services one day and stumbled across a method for collecting real-time ßight information from every major airline. He turned this into a web app that any web user could access for free to check ßight status on-demand. It even works on mobile devices via SMS messages. He set up an ad-based revenue model for the site, hired a team, and now he spends most of his time hanging out on the beach. His dad told him he should get some life insurance. Oh, and he’s crazy rich."

If you design a site to help Daniel choose a life insurance plan, what happens when Greg shows up? The things you put in place for Daniel, the stock broker, are probably going to irritate Greg. Greg is impulsive, wants to get things done fast, and, let’s face it, probably won’t understand or care about most of the information on the site anyway. But Greg is young and rich, so he’s a far more valuable customer than Daniel.

How do you design for Daniel without losing Greg’s business?

See the problem? UCD leads us to the creation of fictitious people moving through fictitious scenarios, but a whole lot of things can go wrong when fiction clashes with reality.

Still not convinced that UCD has issues? Try on these final few points.

First, developers like tangible problems they can solve. Many developers just want you to tell them what to build so they can get on with figuring out how to build it. And, they’re usually on tight deadlines just like the rest of us. Delivering a set of personas to one of these guys is a surefire way to make his eyes roll back in his head.

Second, managers like results. Deliver personas to a CEO or a director of development and, for all that money she’s spending, you’re bringing her a set of what are essentially character descriptions for a movie. Managers don’t want that. They want an application that will start making them money. They want deliverables that deliver real results.

Finally, the design community has proven itself incapable of coming up with a common definition of user-centered design. Most agree that UCD comprises many of the deliverables and steps I outlined in the beginning of this article, and most agree that UCD means putting the user at the center of focus during design projects. Beyond that, though, some say UCD can be performed by simply thinking about the proverbial user while designing, while others say personas are an absolute requirement of every design project.

This lack of a clear definition makes it quite difficult to communicate to professionals in other aspects of our industry exactly what it is we do, and the profession suffers as a result.

George Bernard Shaw once said:

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man."

You may think I’m being awfully unreasonable by telling the design community that the UCD process is broken and that we need a new one. But, in the end, my goal is to help create a system that works. And that, I believe you’ll agree, is pretty reasonable.

But you can’t have a successful product without listening to users, can you?

Yes, yes, you can. In fact, you can often go above and beyond what users think they need by ignoring them during your design process. (Of course, you should back up this decision with knowledge of human behavior so you can design to support it, but we’ll talk about that in the next article.)

In support of this idea, it’s been rumored that Henry Ford once said:

"If I had asked my customers what they wanted, they would have said a faster horse."

In Part 2 of this three-part article, we’ll look at some examples of things that were designed without the aid of UCD, a solution to some of UCD’s problems, and how to achieve truly usable interactions in our designs. In Part 3, I’ll discuss how to put it all together into a design approach that works.

Stay tuned!