User-Centered Design

The goal of talking to the target users is to determine their needs. But nobody knows users' needs better than the users themselves. Instead of asking them high-level task-related questions, as outlined earlier, why not go one step further and ask them low-level detailed questions? Why not involve them directly in the user interface design process itself? Why not have them evaluate the entire user interface design?

Designing user interfaces with the direct assistance of user feedback is the core of user-centered design. A user-centered design process typically includes the following steps:

  1. Talk to users (as discussed earlier).
  2. Quickly design a user interface based on user information.
  3. Create a prototype of the design.
  4. Have users test the prototype.
  5. Repeat the process until satisfied.

In this user-centered process, the user is the key player. The user, not the programmer, is setting the program's goals and requirements based on his needs. The user, not the programmer, is determining what the product should look like and how it should behave. Furthermore, the user has ample opportunity to evaluate the user interface by testing the prototype so that he can identify problems early in the design process. In short, the user is getting exactly what he wants. The programmer is simply implementing what the user asks for in the intermediate prototypes and the final product.

What could be better for satisfying the user's goals? If you do everything the user asks for, how could this process not result in a successful product? How could such a process possibly go wrong? Well, there is one small problem: users typically don't have the knowledge or ability to play this role, even if they want to.

Users Aren't Designers

For users to play such a critical role in the user interface design process, they need the following abilities:

  • Users need to know what they want and be able to articulate it.
  • Users need to understand the solutions possible using current technology.
  • Users need to understand basic user interface design principles.
  • Users need to determine if the prototype is acceptable.

Unfortunately, users typically do not have these skills. The fact that users often lack these skills doesn't mean that they aren't smart—it simply means that users aren't software designers or software engineers and therefore have no experience designing software. However, note that while users can't tell you if a design is good, they can certainly tell you if a design is bad. They can tell you whether they understand it and can perform tasks with it. They can tell you if they are confused or don't know what to do next. User testing is the best way to obtain this information during the development process and it is discussed in detail in Chapter 27, "User Testing"

Let's look at these problems in a bit more detail. While users are certainly experts on the tasks they perform, the goal behind creating new software is to help users perform the tasks more efficiently and effectively—in other words, differently than the way the tasks are done now. If the tasks are currently performed without software, most likely users will want to perform them roughly the same way with software. Users are unlikely to use radically different thinking or employ new software technology. While users might know how to improve their current process, they probably don't have the ability to translate this directly into a software solution. In other words, they might know what they want in general terms (for example, "I want to access the Internet more efficiently"), but probably won't have a clue how to do that in more specific terms. Likewise, they might not be fully aware of the ways in which software can improve their tasks. Also, it's possible that some users won't have the ability to communicate their ideas effectively. Besides being able to say that they don't like something ("My current Web browser is a pain to use"), they might not understand or be able to communicate specifically why they feel that way.

The fundamental concept behind user-centered design is something like, "We software developers don't know how to design software that satisfies user's goals, so we are going to have users tell us what they want." While a group of users can lead you to a user interface design that they really like, there is no guarantee that other users will feel the same way. If the first group of users don't understand fundamental user interface design principles, this outcome is virtually guaranteed. After all, users aren't designers.

Problems with Prototyping

User interface prototyping holds many promises. Prototyping can help you get user feedback quickly. Prototypes allow you to try new ideas easily, without much commitment. And they allow you to make sure that users are satisfied with the user interface design early in the process before the real development begins—at least in theory.

As noted earlier, for the user-centered design process to work, the user needs to determine whether the design is acceptable by evaluating a prototype. This task is much more difficult than it appears. For a user to identify design problems in a prototype, the user must:

  • Use the prototype long enough to realize that there is a problem
  • Be able to recognize the problem
  • Be able to recognize that the problem lies in the design of the prototype and not in the user's actions
  • Be able to clearly articulate any problems or concerns with the prototype

TIP
Having users evaluate a design through a prototype is much harder than it appears.

Let's consider why these tasks are difficult. The first question to ask is: what exactly is a prototype? A user interface prototype is a mock-up of a user interface. What exactly is a mock-up? Many forms exist, ranging from a paper mock-up to a nearly fully functional user interface, but all user interface prototypes or mock-ups have one thing in common: they are not the real user interface. For a prototype to have any sort of cost or time advantage over the real user interface, it must have some significant functionality missing. While the basic user interface elements will probably be present, many of the details will not. If data is involved, the prototype data might not be real. There might not be detailed features that help the user eliminate unnecessary effort. The prototype might lack error messages and advanced features. For these and other reasons, the prototype won't give a realistic indication of the eventual program's actual performance. However, these details can be extremely valuable in evaluating the usability of the interface. Such details often make the difference between a collection of windows and dialog boxes and a usable program.

Now let's look at some of these problems in more detail. If a user is testing a mock-up user interface with mock-up data, how long can you expect the user to evaluate the prototype? For a half-hour, maybe an hour if you're lucky. Unfortunately, it takes users a fair amount of time before they can identify many types of problems. For example, if a task is unnecessarily repetitive, it might not be obvious from performing it once or twice. But it will certainly be obvious after performing the task a few dozen times when the program is in the real world. Some user interface problems take a while to become annoying.

It can be difficult to recognize even routine problems with a prototype. How so? Suppose you introduce a prototype by saying, "This prototype is a rough idea of what we have in mind. Clearly, the finished product will be different." This seems reasonable to say, but what you are basically saying to the user is, "Don't criticize the details because they haven't been addressed yet. In fact, don't criticize the prototype at all unless it is way off the mark." This is what is often understood, anyway. Even if you explicitly ask users to report every detail they don't like, it is hard to be critical of a prototype that you know isn't the finished product. A user can easily explain away all minor shortcomings by thinking, "Well, this is just the prototype. All these minor problems will be fixed in the real interface."

TIP
It is hard for a user to be as critical of a prototype user interface as of a real user interface.

Users that are unfamiliar with a prototype clearly know that they are unfamiliar with it. Suppose a user evaluating a prototype repeatedly makes a mistake. There is a strong possibility that the user will blame himself for the problem, not the prototype. Such a user is likely to think, "Gosh! I did it again," rather than conclude that the user interface design is at fault.

Lastly, the user needs to be able to communicate any problems or concerns that he has with the prototype. But if an interface is bad, don't expect the user to understand why or how to fix it. Suppose a user says: "I find this task too difficult to do, but I don't know why." How do you interpret this? Is the problem with the user interface design? Is the problem with the incompleteness of the prototype? Is the problem with the user's lack of experience? The only safe conclusion is that it is a problem with the user interface design. Now how do you fix it?

I clearly have a problem with the overreliance placed on functional prototyping (prototyping with operational software) in the typical user-centered design process. The effectiveness of prototyping cannot be taken for granted. To find many types of problems, you need to test real software with real data using real tasks. While I believe users should play an important role in the user interface design process, there is a limit to what they can do. They can't turn a poorly designed program into a well-designed program. At best, they can turn a poorly designed program into a usable poorly designed program. On the other hand, I do believe that prototyping can be a very effective technique for solving specific user interface problems. Moreover, I prefer nonfunctional prototyping techniques—such as prototyping by example, paper prototypes, scenarios, and resource prototypes—to functional software prototypes. I'll discuss these issues in detail in Chapter 14, "Prototype with Caution"

Many of these functional prototyping problems can be addressed by evaluating the prototype with a proper user testing procedure, as described in detail in Chapter 27. You can obtain valuable information by combining prototypes with user testing. The problems I describe here can occur when functional prototypes are not combined with user testing, which I have seen happen quite often. To solve many of these problems, you need to actually watch users test the prototype and you need to ask them to think out loud while they use it. This way, you directly experience the problems instead of relying on the users to communicate and interpret them. You can't just hand users a functional prototype and expect them to give you useful feedback.



Developing User Interfaces for Microsoft Windows
Developing User Interfaces for Microsoft Windows
ISBN: 0735605866
EAN: 2147483647
Year: 2005
Pages: 334

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net