Design Feature: March 3, 1994

Videotapes of test users following carefully constructed scripts can reveal the kinds of problems real users would encounter and can suggest changes that will improve the product's usability. The tapes should capture users' explanations of their thoughts as they attempt to interpret the cues and prompts provided by the simulated product.

With today's compressed development schedules, once a user interface exists in hardware, it's often too late to change it. If you can't make needed changes, your company will just have to try to persuade customers that the quirks they find so frustrating are really "features." But user testing doesn't have to wait for hardware availability. You can choose from a surprisingly large number of software tools to construct your prototype or simulation before you commit to a hardware design. (See Table 1.)

The products in the table range from high-end workstation-based ESDA (electronic-systems-design-automation) tools to mass-market software products for PCs running MS-Windows and for Apple Macintosh systems. The tools include several that cost only a few hundred dollars—within the reach of even the smallest development budgets. The prices range upward to 10s of thousands of dollars.

The major difference between the most expensive tools and the least expensive is how much of the design process they handle. More expensive tools usually output VHSIC hardware-description language (VHDL) or Verilog code. Some also produce output in a high-level language such as C. When the target product is an embedded system, the C code rarely if ever is ready to compile and load into ROM. In nearly all cases, the code needs optimization by an experienced software engineer. However, some suppliers say that users can transform their tools' VHDL code into usable devices without further optimization. And several products claim to generate high-level code that needs no optimization to compile and run on general-purpose computers.

Products that do less of the hardware design work usually provide an output that describes the operation of the user interface. You might substitute the description for a specification document, or the description, along with the running simulation, might complement the specification. At the very least, a software engineer should be able to use the description to write code that makes the real user interface function like the simulation.

A number of the packages in Table 1 were developed for data-acquisition and instrument control rather than for user-interface simulation. (Examples are HP VEE, DT VEE, Wavetest, Wavetest VIP, LabView, LabWindows/CVI, Realtime Vision, TestPoint, and VisuaLab.) Nevertheless, these packages permit you to construct "virtual front panels" that, in many situations are quite good enough for prototyping user interfaces and, in some cases, go well beyond the minimum requirements for such simulations. For example, if you were designing a stand-alone digital oscilloscope, you might find a use for a package's ability to display waveforms acquired by an ADC on a data-acquisition card.

In the classical approach to user-interface design, a project team creates a user-interface specification document from which designers try to work. Such documents tend to be very long and detailed; producing them takes lots of time, and they have a major problem: After reading just a half-page or so, most readers' eyes glaze over. You can nod because you agree with what you are reading (or because reading the spec puts you to sleep), but when something actually operates the way the spec describes, you may well wish that it worked differently. At the detail level, words can't convey how a user interface operates. The description of how a meter's menus work (see box, "Simulating a DMM") demonstrates the problem.

Simulations convey much more meaning than descriptions do. But to be useful, a simulation must be more than an artist's conception of a product's front panel or a computerized slide show indicating the displays that appear in various machine states. A simulation must be interactive; it should let you "push" buttons by clicking a mouse on their images and "rotate" knobs by dragging their pointers from one position to another. Of course, a simulated fax machine probably won't scan documents and send them as faxes, but a simulated alarm clock might actually display the correct time.

In some instances, you may decide that your screen displays must look like the real thing down to the most minute detail. For this purpose, certain tools are better than others. One tool for providing great realism, including animation, without excessive effort is Altia Design. Several tools, including the Altia package, accept scanned-in photos of existing products—a feature that can prove particularly useful when you upgrade a design. The realism of such images can leave test users in awe, but beware of devoting too much effort to the cosmetic aspects of a simulation. Your objective should not be to impress your test users; it should be to gather their honest reactions to the way the user interface operates.

Nevertheless, constructing and testing a simulation can be time-consuming, and you might think that putting these activities at the front end of your project would slow you down. But many in the industry disagree. Designing a good user interface is an iterative process (Ref 2). If you decide on an approach without testing it, the probability is high that you will have to backtrack and repeat lengthy steps. Once you become familiar with your simulation tools, you can change a simulation much faster than you can change a hardware prototype. You can even make changes at a customer site and obtain feedback almost immediately. That's why simulation is a timesaver for most projects.

Different tools provide different ways to create simulations. Some (Toolbook and Plus, for example) provide scripting languages. Such languages have an English-like syntax that is relatively easy to learn, read, and interpret. One well-known scripting language is Hypertalk, used in Hypercard on the Apple Macintosh. Other tools work as adjuncts to standard high-level languages. Add-on products (for example, VisuaLab and Gadgets for Windows) enable you to use Microsoft's Visual Basic and Visual C++ to construct user-interface simulations. (See box, "Looking ahead.")

A third method of describing system behavior to your simulation tool involves using a graphical metaphor. With some tools, you can draw state diagrams on a PC or workstation screen. Examples are StateCAD ($995) and BetterState ($1195) among Windows-based tools, and i-Logix's Statemate, which runs on workstations. These packages produce VHDL outputs. With Statemate and BetterState, VHDL is only one of the options. StateCAD produces a VHDL dialect, Abel (from Data I/O, Redmond, WA). Whereas Statemate produces simulations as well as code, creating a simulation with the two Windows-based packages would require linking the code to another tool. One such tool is Altia Design for Windows 3.1, which may be ready by the time you read this.

With VI Corp's tools, you describe a product's behavior by interacting with dialog boxes. For example, in each machine state, actuating any object—that is, a button or a knob—causes certain results. (If the object is a 12-position rotary switch, the results might be different at each switch position.) The dialog boxes provide a structured way to describe these results. Most user actions cause the product to move to a different state, although sometimes there is no state change. The next state can be one that you've already defined or one that you haven't yet defined. If you haven't yet defined the new state, the dialog boxes let you describe the effects of operating the controls in that state.

Regardless of the type of input your simulation tools require, if you attempt to take a short cut on user testing, your simulation has little value. Moreover, to derive the maximum benefit, you must do your user testing properly.

First, recognize that people close to your project are not representative users; they are too close to the problem to be objective. For example, you might know that if users find certain aspects troublesome, changes could increase the product cost. Such a bias might close your mind to needed changes. If you've designed the simulation yourself or if you work closely with someone who did, you already have much more information about the product than most first-time users have. Moreover, you are an engineer; unless your product will be used only by other engineers, your thought processes differ from a typical user's.

A big benefit of user-interface testing is that it puts designers in contact with the people who will use their product. The interaction between designers and users can be of tremendous value if the designers keep an open mind, if they listen to the users, and if they restrain themselves from "setting the users straight" about their "incorrect" thinking.

Don't become so committed to an approach before you begin testing that you try to browbeat your testers into telling you how wonderful the design is. Testing involves restraint. Prepare a script in which you ask the testers to perform certain tasks. The scripts should not contain loaded questions that lead users to correct answers. Don't ask "What buttons would you push to invoke the XYZ function?" Instead ask "How would you invoke the XYZ function?"

Don't try to make testing easier by assembling large groups of testers, say in a focus group; the testers will learn from each other. In such situations, only the first of the testers will have the mindset of a first-time user.

Another pitfall is to send simulation diskettes to the test users with a request that they let you know their reactions. Even if you call the testers and question them after they've had time to "play," you won't obtain valid information. The only way to obtain useful information from most testers is to ask them to achieve well-defined results and to elicit their reactions while they try to obtain those re- sults. Videotapes of such tests can be useful to you in comparing the reactions of users and to make points to colleagues who can't witness the actual testing.

Attempts to elicit testers' reactions after the fact can be extremely misleading. This phenomenon partially explains why many engineers think that products that really cause users a great deal of trouble work just fine. Many users feel that criticizing isn't polite. Moreover, users often forget about problems they have overcome.

One human-factors engineer insists that unless there's a compelling reason for a product to behave otherwise, every reasonable action by a reasonable user should produce the result that the user expects. I tested a simulation of one of this engineer's designs—a fax machine—and found the experience nothing short of delightful, especially after my experiences with EDN's fax machine from hell (Ref 3).

But Dr Gene Lynch, who heads the human-factors laboratory at Tektronix Labs, feels that, although this principle might seem reasonable, it can backfire. People's thought processes are so different that each of a product's functions might have to be accessible via a half-dozen control sequences. Lynch claims that this requirement greatly complicates writing and testing microcode and increases the likelihood that a product will not operate reliably.

One prototyping-tool vendor agrees that multiple paths increase the likelihood of unreliable operation, but the company says that it has developed proprietary techniques to assure the integrity of its tools' output code when there are multiple paths to various states. Some engineers don't agree that prototyping tools require such safeguards, however. They claim that only rarely is it much more difficult to provide multiple paths to each of a machine's functional states than to provide just one path.

References

1. Norman, Donald A, The Design of Everyday Things, Doubleday Currency, New York, NY, 1988, ISBN 0-385-26774-6.
2. Nielsen, Jakob, "Iterative User-Interface Design," Computer magazine, November 1993, pg 32.
3. Strassberg, Dan, "Designing It Wrong: The Fax Machine from Hell," EDN, October 1, 1992, pg 33.

Acknowledgment

Scott Miller of Hewlett-Packard, San Diego, inspired me to choose this topic and provided some of the material on which the article is based.