Microsoft has a lab for it; so does Apple. IBM probably has several (one for each of the breakaway republics). Lotus and Tandy and Borland send theirs out.
It's not fundamentally new, this business of testing software for usability. Human-factors research is the basis of usability testing, and that's been around longer than personal computers. Usability testing is human-factors research swallowed up by the voracious software development cycle.
But it's not even new as a snack for that time- and energy-swallowing appetite.
The current trend is the second era of personal computer software usability testing. There was an earlier, now legendary, era in personal computing when usability testing was used to be sure that the target user could actually use the product. That was back in the early days of personal computing, or microcomputing, back when the user looked and talked and thought just like the developer because the user was a developer. Or a hacker. Or a hobbyist. Or an enthusiast. Or, like the customers I dealt with when I did service calls for a computer store back in 1979, a pioneer who, for obscure reasons, was willing to work with a few arrows sticking out of his or her back.
During that wild and innocent era, usability testing meant passing the product around among your friends. It was beta testing, to give it its proper Greek letter; there was no important difference then between beta testing, usability testing, and showing the product to your pals (that is, to those pals who were in the know).
That era ended in 1981, but for the most part the entire personal computer software industry has continued to rely way too long on beta testing and the feedback of insiders who are not the target audience for its products.
Usability testing means letting the target users try the software, monitoring their behavior, analyzing their comments, and setting them tasks that test specific aspects of the ease of use and naturalness of the user interface. Psychologists in lab coats watching their subjects through one-way glass.
But Apple's human interface guy, Bruce "Tog" Tognazzini, says it doesn't all have to be that formal. In the October 1991 Apple developer newspaper, Apple Direct, he presents a case study of a very casual usability test. Although Tog has the lab-coated testers available to him, he knows that most developers don't have Apple's resources. "I believe that you can do your own initial testing if you can overcome your own biases, and if you can find a group of dear friends who will support you." One bias that Tog may have had to overcome: One of his dear friends pointed out that the Macintosh control Tog had defined shouldn't be incompatible with the behavior of a similar control in Microsoft Windows.
Informal usability testing is only part of the process, though. It can identify problems, but it can't identify the absence of them. For that you need a more formal testing procedure, and a representative sample of your target users.
Here's an example of what not to do with usability testing.
Copyright © 1992, Dr. Dobb's JournalWhat It Was
What It Is
What It Ain't
The computer magazine that recently did all of the above probably should have run the idea through a usability lab first.