Authors:
How many times have we been asked to evaluate a client's
Web site or software application for usability? All the
design guidelines and standards we have at hand, all the
usability tests we conduct, do not ensure that the client
will accept our verdict or our recommendations. Larry Marine
describes four rules that he has developed to improve the
user-centered design methodology and tells us how he uses
them to increase the objectivity of his evaluations and make
the bad news more easily accepted by the client.
— Elizabeth Buie
"Your baby is ugly!" That's just about how it feels when we are asked to evaluate our clients' products. Our clients have invested a lot of effort and emotion in their designs, but typically not much analysis—so their designs often miss the mark, and grotesquely so. When they call us, we have to tell them what they already know but don't care to admit: Their baby is uglier than a three-legged warthog with a sinus condition.
Everyone has opinions (and emotions) about product design, but to evaluate a design well, you need to divorce yourself from your opinions and assumptions and start looking at the design objectively. To ensure that a product design is based more on fact than on opinion, I follow a standard process. Of course, opinions sometimes do count, but usually only when heuristics conflict and you need to make a decision on what direction to take.
I developed my process from the familiar user-centered design (UCD) methodology. To the UCD methodology I added four basic rules:
- Get client buy-in
- Question assumptions
- Focus on the business and user objectives
- Evaluate tasks, not features
Let's look at how these rules work.
Get Client Buy-In
How do you get clients to buy into the result of an evaluation? If you have done your job well, you'll have a long list of design issues. This can make it difficult to "sell" the results to the client. You must manage your clients' expectations, to ease the blow of seeing an unflattering evaluation report.
I get this buy-in by making the client part of the process. Not only do I benefit from her domain expertise, but she participates in the evaluation. Since the client and I share responsibility for the design, I need to move them away from their emotional attachment toward an unbiased analysis of the fit between the design and the tasks and objectives. In a sense, I am tactfully helping them realize that although their design may be good, it doesn't fit their objectives. This is a lot different from telling them their design is bad. It's merely stating that the design and the tasks don't match.
Make Them Part of the Process
How do you get clients involved? Start by getting them to define the business goals that the product must support. But don't expect them to have that answer ready. I often find it helpful to get them to describe the objectives to me first, then later commit to them.
I once worked with an executive team in New York. The five executives in the room gave me five different business or marketing objectives. This revealed that, even though they all thought they had the same objectives, they were all directing resources to achieve competing objectives. By the end of the day, they had agreed on a single basic direction. It all came down to the bottom line. It always does. All you need to do is help them verbalize their product's business model. It doesn't have to be right; it may change after your first round of user observations, but you need to get consensus. This approach gets them accustomed to participating.
The real participation has to occur at the outset. You have to get consensus on the goals of the product and who the target users really are. If you don't have the client's consent at the outset, then no matter how well you evaluate their product, it's a poor evaluation if you evaluate the wrong tasks and objectives. So the first step to getting buy-in is to get the client to help you identify the product's objectives.
Question Assumptions
One factor is critical to achieving objectivity in design: Question your assumptions about the design or domain. More often than not, a product design is based on outdated assumptions.
One assumption that I routinely question is what actual task or process will the product address. Often you can improve the product by improving the process, task, or objectives. I call this redefining the problem. (This is another case in which the process can benefit from the client's expertise and you get his buy-in.)
Care should be taken when asking these questions. Done improperly, the client may feel that you are either obnoxious or ignorant, neither of which you want. Recognize when the questioning isn't generating new results, and move on. But when you feel you are getting somewhere, don't stop until you get there. The key to success is to ask questions that take small steps. Ask questions that require the client to take a leap of faith, and you'll probably miss your target.
Focus on the Business and User Objectives
Every product must have a purpose. The trick is to figure out how this fits into the company's business plans. The product's purpose includes both business and user objectives. Don't be surprised if you find that the client's objectives are based on vague assumptions, so be prepared to question these as well. Don't get hung up on getting the client to change his objectives; your job is to achieve clarity.
Let's explore some common business and user objectives. As you read about them, consider the different design directions you might take to address each one. In doing so, you should begin to recognize that some design directions conflict with others. For this reason, it is essential to get consensus on a single design objective so that such conflicts do not hit you in the design phase.
Business Objectives
Every product or site has a business objective to meet. Some common ones include capturing new customers and extending the relationship with existing customers.
Before you can begin to evaluate a client's product, you must fully understand the intended result of its use. For instance, an e-commerce site must let shoppers complete their shopping experience as efficiently and effectively as possible. A medical device must satisfy the medical need quickly and without any errors.
New Customers
Although getting new customers seems like an obvious business objective, we explore it here because it means something specific with respect to evaluating the design. Getting new customers means that the design doesn't need to maintain any existing interface or interaction styles. All too often we see designs that have multiple personalities, trying to assuage a very small installed base while wooing a large untapped user pool. The business objective of winning new customers must be clear and decisive. If it is not, you'll need to insist that the client make a decision. If they can't decide, you can always charge them double and give them an evaluation based on both user sets.
Extending theRelationship
The client may want existing users to use more of his products. From a design perspective, this means that you should be looking for consistency in design as well as opportunities to encourage users to discover for themselves the need for additional products. This business objective would drive the evaluation to identify inconsistencies in the visual and interactive styles; otherwise, users will encounter too much unfamiliarity as they move from one product to another. Doing the same thing in different ways requires unnecessary effort, so inconsistency will discourage users from extending their relationship with the client's products.
User Objectives
Design has one major purpose: Modify users' behavior. This is like animal training, in which whale trainers get whales to do things that they would do anyway, but in a predictable and controlled manner. A good design encourages users to do things that they are naturally inclined to do, so that they succeed at tasks that support the product's business objectives. The trick is to get them to do the right behaviors at the right times.
To understand the users' objectives, you'll need to know who the target users really are. You can get a preliminary list from the business objectives. Refine this list by considering the tasks that the client intends the product to address, and you should be able to build a short list of user types.
Evaluate Tasks not Features
If you follow standard UCD processes, you will have completed some general user profiling and task analysis to round out your list of user types. These tools provide the key to a successful evaluation, in which you walk through the primary tasks, posing as the principal user "persona," and attempt to complete the tasks. Your evaluation ratings should be a measure of the difficulty (or ease, for a good design feature) in achieving the tasks given the user characteristics.
A good design should solve the users' problems.
If you make the common mistake of evaluating by features instead of by tasks, your evaluation may not reflect the product's ability to meet the client's objectives. For example, if you look at each screen, you can give high marks to a design that doesn't allow users to complete their basic tasks. For instance, you may find that a report generator is designed well, but your user base may be unfamiliar with generating reports or may run the same reports every time. No matter how well it is designed, it doesn't fit the principal users or their tasks.
Designs that center on features also serve to automate the users' current frustrations. A good design should solve the users' problems. Many designs place too much responsibility on the users to solve their own problems in completing tasks. This fails because these designs are often based on the assumption that the users know what to do. More often than not, they don't.
It is easy to look at a product and declare it well designed for a particular task. However, your goal is also to determine whether the users' tasks should be modified to better meet the business objectives. Good product evaluation looks at the task as a whole and evaluates the screen or page flow to ensure that the process is as user-friendly as the design. Sometimes this means looking to see whether the design could have done more of the work for the user instead of making the user do unnecessary work.
Example: Automating the Current
Frustration
One of the most common design flaws we see are designs that merely take the current process and automate it. The assumption is that the current process is as good as it can be, which it rarely is. Inevitably, most designs merely enable users to make the same mistakes faster and more easily.
A successful design should take some innovative liberties and address processes as well as the interface and interaction styles. Let's look at the report generator, for example. Typically, report generators expect the user to know what's needed and to enter just the exact parameters that produce a report containing the desired results.
When people run reports, however, they generally are looking for trends or exceptions. A better report generator would automatically "run reports," look for interesting information using various parameters, and then list all of the interesting trends or exceptions. This innovative design approach harnesses the power of technology to achieve the users' goals with less effort than the current process, but it came about only after we questioned the assumptions of what report generation should be like.
Take Stuff Away until It Breaks the
Task
Another way to evaluate a design is to remove controls, information, or features until the screen or Web page no longer satisfies the task. Every design I've seen has had features that could be removed without degrading the task. At some point it will become obvious that some features, although nice to have, just don't support a client's business or user objectives, and the evaluation process helps them identify what changes are needed. For instance, I've seen stock tickers on screens where a change in stock price will have absolutely no effect on the users' behavior. Sure, it might be nice to have, but to a user in the middle of filling out shipping information, a stock ticker will only distract.
Your Baby is Objectively Ugly
I credit my success at design evaluation and client problem-solving primarily to the UCD process, plus the four rules I've described here. They help achieve unbiased results the client believes in. Of course, it's easy for me to write about these rules in an article, but it's quite another to make them work in the real world. Despite my successes, I still find it difficult to apply all of these rules all the time. Nonetheless, I can't imagine evaluating a design without them. Without these rules, no client would believe her baby is ugly.
Author
Larry Marine
[email protected]
Larry Marine, user-experience designer, teacher, writer, and volunteer, has stuck with the usability thing since his mentor, Don Norman, told him to start Intuitive Design back in 1990. Larry loves his work and says the best part about it is working with so many different types of products—software, Web, and medical devices, to name a few. He now knows just enough to be dangerous on almost any subject.
Whiteboard Column Editor
Elizabeth Buie
Senior Principal Engineer
Computer Sciences Corporation
15245 Shady Grove Road
Rockville, MD 20850
+1-301-921-3326
fax: +1-301-921-2069
[email protected]
©2002 ACM 1072-5220/02/0900 $5.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
Post Comment
No Comments Found