April 20, 2001 issue psTech: 28A
by Jerrold Prothero, Ph.D.
President & CEO
Hypercerulean, Inc. \u2013 Seattle
In the gold-rush days of the web, it was truly remarkable how little money was spent by start-ups on usability
testing. What was even more surprising is how few investors insisted that usability be built into the development
process. Had investors demanded
Investing millions in a failed venture is no joke. Nonetheless, there is a little witticism in the usability community
that says the typical product development life-cycle consists of the following steps: design it; build it; test it; find out
it doesn\u2019t work; and ship it, because there isn\u2019t time to do anything else. This life-cycle produces an enormous
number of expensive customer service calls, in addition to losing customers entirely. The saddest truth of all may be
that the lack of early and consistent usability testing may have been the root cause for many dot.com meltdowns.
While we all understand that software engineering is concerned with a product\u2019s functional requirements, we are
often unaware that \u201cusability engineering\u201d is concerned with the customer requirements for a product. Usability
engineering starts from the customer\u2019s perspective, proceeds to the design of an interface to meet the customer\u2019s
needs, and then addresses the functionality needed to support that interface design. The interface is how customers
interact with the product: from the customer\u2019s point-of-view, the interfaceis the product. Ease of interaction is the
critical factor in the success of new products. A good interface can make up for bad functionality; but good
functionality can not make up for a bad interface.
A common (and damning) error in web site development is to focus primarily on the site\u2019s appearance. The
telephone book is not in every home and office because of the quality of its graphical design. It is there because it
efficiently satisfies a need. In my years of usability testing for web sites, I have never had a participant pound their
fist on the table and shout \u201cthis site needs better graphical design!\u201d Complaints about confusion or difficulty using a
site, on the other hand, are continuous. In one case, a polite comment was: \u201cI still don\u2019t know what motivated this
company to exist\u201d.
Currently, development decision are often made in meeting on the basis of competitive hand-waving, when they should be made on the basis of usability data. The interface can and must be designed, prototyped and customer tested from the very beginning of the development process. This includes inexpensive customer testing of early paper prototypes, which can provide valuable feedback on general task and layout requirements.
Developers and investors have a lot in common; they are often too close to the product to be able to see usability
problems from the customer\u2019s point-of-view. Both need to see and hear how potential customers are reacting to the
early build-out of a product. When monitoring an investment, would it be better to be routinely reviewing usability
test results from an objective 3rd party, or to look over another notebook of \u201ctasks completed\u201d at an \u201ceverything\u2019s
great\u201d presentation? Which of these brings the venture closer to a profitable product?
My corollary of Murphy\u2019s Law is that anything that hasn\u2019t been tested, doesn\u2019t work. Everyone knows this for
software. If you haven\u2019t tested software, it will fail. Exactly the same thing is true for interfaces. If they haven\u2019t been
tested, they won\u2019t work. The difference is, when software fails, it is usually obvious. Something crashes. When there
is a problem with the interface, it is much more subtle. You simply annoy potential customers, who disappear.
Interface usability problems are as insidious as high blood pressure: they kill you, but they kill you quietly.
This action might not be possible to undo. Are you sure you want to continue?