The whiteboard

IX.5 September 2002
Page: 35
Digital Citation

“Pardon me, but your baby is ugly…”


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.

 

VSPACE="2"> 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.

 

VSPACE="2"> 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.

 

VSPACE="2"> 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.

 

VSPACE="2"> 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.

 

VSPACE="2"> 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.

 

VSPACE="2"> 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.

 

VSPACE="2"> 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

  LMarine@IntuitiveDesign.com

 

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

  ebuie@csc.com

 

©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