Usability Myths

Posted by on May 5, 2011 in Usability | One Comment

Here is short article I wrote in the early 2000’s when I had my own design consultancy, Interaction Architects. I thought it would be interesting to post it now, over 10 years later, and see how many of these myths persist even today. These myths were written based on my own experiences and some were borrowed from the writings of Marc Chrusch(1) and Jakob Nielson(2).

  • Myth 1: Usability Increases Development Costs and Time
  • Myth 2: User Interface Is Just Good Graphics
  • Myth 3: Usability is Achieved Following Guidelines & Standards
  • Myth 4: Usability Is Achieved Using Standard Objects
  • Myth 5: Usability Is Just Common Sense
  • Myth 6: We Already Know the User and What They Want
  • Myth 7: Real Users Don’t Mind Complex Design
  • Myth 8: We’ll handle “That” in the Help / Training / Documentation
  • Myth 9: You Do the Front-end While We do the Backend

MYTH #1:

Usability Increases Development Costs and Time
It is true that usability activities do not come for free, however, if properly used and applied they can actually save time and money. When usability is treated as an afterthought or as a component of final quality assurance (QA) testing, costs increase since design changes after code-complete is a time-consuming and expensive endeavor. Industry data show that each dollar spent on user studies during product design saves $10 on problem fixes during product development, or $100 or more in rework after product release(3). It is estimated that 80% of maintenance costs are spent on unforeseen user requirements, while only 20% are due to bugs(4).

MYTH #2:

User Interface Is Just Good Graphics
Do not misinterpret the visual design of an interface (the look) as the only component of the interface itself. Doing so overlooks the entire interaction aspect (the feel) of the design. While the look of the interface conveys functionality and establishes its character and brand, the feel created by information and interaction architecture is directly related to the ease of learning, ease of use, efficiency, and user productivity. Thus, both the look and feel components are essential to a successful and well-balanced design.

MYTH #3:

Usability is Achieved Following Guidelines & Standards
Following any set of guidelines does not ensure a usable interface. Guidelines can ease the design process by reducing the number of look and feel decisions and helping to keep those decisions consistent. Additionally, guidelines tend to be general in nature and do not address the specifics of a given problem. A guideline may state, for example, “Allow the user to cancel a potentially destructive action;” however, it does not specify how to accomplish this. Thus, interpretations of these guidelines can yield many different design solutions, good and bad.

MYTH #4:

Usability Is Achieved Using Standard Objects
The myth goes as follows: Everyone knows how to use standard user interface objects like check boxes, radio buttons, scroll bars, etc. Thus, use of these standard objects should result in usable interfaces. This is the same as saying the use of standard Lego blocks ensures a recognizable and usable creation. When these standard objects are used, one creates micro-usability. In other words, the user knows how to check or uncheck a check box. However, will the user know why to change its value? What information will the user need to make a decision? At what point in a process should the user consider checking the box on/off? The check box object itself does not address these issues. These more global, task oriented issues are related to macro-usability and are addressed by interaction designers.

MYTH #5:

Usability Is Just Common Sense
If this were true, then why are so many products difficult to use? Why is there such concern over training, customer / technical support, and ease of use? In a strange way, usability engineers themselves are partially responsible for perpetuating this myth! A successful usability engineer creates solutions that meet user needs, thus the solutions seem natural and intuitive; in other words, the interface is invisible. This means the interface was designed so well that users can pay more attention to their tasks and goals instead of the mechanics of how to operate the interface. Consequently, such finished designs garner comments like “…of course, this is so obvious“, or “Why would you do it any other way?” Hence, the notion that if the end design looks like common sense, then it must have taken common sense to produce it.

MYTH #6:

We Already Know the User and What They Want
This is a three-part myth:

Part One: It is absolutely possible for you to know your end users and what they want. This is a start, but it is not enough. For example, knowing that end users want feature X says nothing about why they want it, what do they do today with or without it, how do they use it, when do they use it, how often, and in what context. What information, artifacts, and skills support their actions and decisions? Lastly, focus groups, interviews, and typical market research capture what people say. Unfortunately, it is a well-known fact that what people say differs from what they do. Interaction designers and design researchers not only listen, but also watch. They are experts in collecting detailed data that is used to drive design decisions.

Part Two: Since your team has worked within your users’ domain a long time and already knows them and their needs, usability testing is not needed. This is akin to saying that since your developers have programmed for a long time and already know programming strategies and several languages, testing is not needed. Database models are validated with walkthroughs, and database designs are tested. Program modules are designed, implemented, tested, and redesigned if necessary. System architecture is validated. Integration testing can last weeks. Like any other software aspects, interface and interaction design also needs to be validated by user testing.

Part Three: “We (development team) use the product all the time; therefore, usability testing will not reveal anything useful we don’t already know.” The problem, of course, is that the development team does not have the same job as the product’s end users, thus they don’t have the same goals, tasks, knowledge, context, or skills. Also, having built the product, the development team is so intimate with its operations and idiosyncrasies that any difficulties cease to be noticed.

MYTH #7:

Real Users Don’t Mind Complex Design
Enthusiasts sometimes defend bleeding-edge technology and complex designs with the claim that users actually like sophisticated products. Users, they assert, are smart enough to handle complicated design. It is not a question of whether users are capable of overcoming complexity and learning an advanced user interface. It is a question of whether they are willing to do so. Usability studies with users who had immense computer experience, great aptitude for technology, and high levels of IQ and education reveal that these users are just like anybody else: they just want to get their work done. They face plenty of complicated problems in their own work, and they don’t want to devote brain cells to your design. They want to get in, get out, and move on with their own tasks. Design complexity is a barrier for all users. While they certainly might be capable of jumping the barrier, why should they? Anything that stands in the way of immediate task completion will negatively impact the user’s experience.

MYTH #8:

We’ll handle “That” in the Help / Training / Documentation
This can also be read as “we’ll give users a half-hearted attempt to address poor design by giving them workarounds with other materials.” Such tactics are ineffective band-aids for poor design:

  • 9% read the printed “Users’ Guide”; 80% skim it.
  • 11% read printed tutorials; 26% skim them.
  • 11% read printed reference manuals; 46% skim them.
  • 17% read printed reference or hint cards; 35% skim them.
  • 7% read online documents; 54% skim them.
  • About 40% say they run online tutorials.

I am not using this information(5) as an argument against help or documentation. I’m simply saying that you cannot reliably depend on them to overcome usability problems. However, there are more tightly integrated forms of help which blur the dividing line between product and help. Ideally, we design to avoid the need for help, but when it is needed, it should be integrated, seamless, just in time, context sensitive, and flexible.

MYTH #9:

You Do the Front-end While We do the Backend
Systems architects have created fantastic designs in which many layers are created that are supposed to be technically independent of each other. Thus, many companies ask designers to proceed with the front-end UI design while the development team works on the backend database and business rules. However, these “lower” or “backend” layers can still be affected by the requirements of other layers. Once the designer presents proposed design solutions, the backend engineering rework begins to accommodate previously unknown information needs, information combinations on one screen, different information formats, and interaction requirements.

More to Read:

 

– – – – – – – – – – – – –

(1) Seven Great Myths of Usability. Interactions, September & October 2000, Vol VII.5, pp. 13-16

(2) AlertBox February 4, 2001, http://www.useit.com/alertbox/20010204.html

(3) Pressman, R.S. (1992). Software Engineering: A Practitioner’s Approach. McGraw Hill, NY.

(4) This information comes from the IBM ease-of-use website: http://www.ibm.com/easy). Specific reference at http://www3.ibm.com/ibm/easy/eou_ext.nsf/Publish/23

(5) Spool, J., et al. Eye for design. User Interface Engineering (July-August 1997).

1 Comment

  1. Jon's article tool
    January 28, 2015

    It’s neaгly impossible to find experienced people abߋut this
    topic, however, you sоund like you know whjat you’ге talking aboսt!
    Thanks

    Reply

Leave a Reply