One of the implications of Moore's Law, which states that processing power doubles about every eighteen months, is that in about eighteen months you'll be able to buy products that are twice as complicated as the ones you can buy today. This seems inevitable in a commoditized electronic products marketplace, in which manufacturers seem only able to compete based on the number of features they can fit into a product.
The twin trends of technology products are smaller form factors are more features. This leads to what I call the "features/usability bind", in which smaller devices with smaller physical UIs have to access larger numbers of functions. Inevitably, this ends up requiring that input devices (even simple pushbuttons) have to become multi-function; even if the interface remains relatively simple, the underlying functional logic becomes more complex. Furthermore, unless the problem is addressed at the level of the functional logic, complexity will continue to grow with proportionally with features. Perhaps this is why so many electronic products are returned as defective because people can't figure out how to use them.
Engineers have often stated that they expect technological progress to hit a brick wall when the laws of physics catch up with Moore's Law and no more transistors can be crammed onto a chip. I think the real brick wall of technology isn't the number of transistors that can fit on a chip, but rather the number of rules that will fit in a user's head. After all, the user has to learn and remember all the rules that govern how the product works; if these rules aren't intuitive, they must be learned by rote, or the user will simply decide that the feature isn't worth the effort.
I think that there are three basic classes of usability problems associated with electronic products today: modes, convoluted functional logic, and hidden functions. Let me briefly describe each, as I see them.
The technical definition of "modes" from a UI perspective is when the same user action produces different results when the control or system is in different states. A mode error led to the crash of an Airbus A320 in Strasbourg, France, when the pilot, attempting to dial a 3.3 degree flight path angle into the autopilot, instead selected the vertical speed mode, causing the value to actually be 3300 feet per minute. Mode errors in consumer electronics products don't usually have such dramatic consequences, but they can be annoying. One that I typically encounter is when I try to change the channel on my satellite TV receiver but instead cause the TV to revert to "tuner" mode because the remote was in TV mode, and the TV thought I was trying to change its internal tuner channel. A lot of people have come up after presentations to tell me that they've tossed the universal remote control and gone back to the five separate ones because they were tired of making similar errors all the time.
Convoluted functional logic is when accessing a function requires following a complex or hard-to-recall series of steps. For example, storing a phone number in a speed dial location of a phone that I have requires you to press PROG to put the phone into "program" mode, then press the speed dial button where you want to store the number, then dial the number on the keypad, then press another speed dial button labeled MEMORY which, when the phone is in program mode, stores the number you just typed into the memory location you selected at the start of the sequence. Then, you press PROG to take the phone out of "program" mode and put it back into "phone" mode. (This example has the added benefit of again demonstrating a problem with modes.) Another example would be that, on a minidisc recorder I used to own, you had to press and hold the RECORD button and simultaneously press the VOLUME button in order to select manual record level. Have you ever had trouble figuring out how to turn off the alarms on a hotel clock radio? Convoluted logic was probably the culprit.
Hidden functions are typically press-and-hold functions that aren't revealed anywhere in the interface. A friend of mine had to leave a car wash once because he couldn't get the antenna down; when he pressed the radio POWER button, the system would alternate between radio and CD player. It turned out that he had to press and hold the button for a second or so in order to actually turn the power off.
I'll bet that most of the problems people have using products are due to one of these three classes of problems, and not to poor design of the interface itself. One of the ironies is that modes, for example, are often intended to simplify product use by collecting similar functions into the larger umbrella of a mode. But then the user has to learn about the modes, and they themselves become a source of complexity. This is why mode errors have been implicated in several aircraft accidents and at least one cruise ship accident in recent years.
Ultimately, these three classes of problems represent rules that the user must learn and remember. I think we're already at a point where people don't use all the features of products they already own, so trying to sell them new products based on additional features may soon become a losing proposition.
In my view, the best way out of the features/usability bind is to decouple the conceptual complexity of the product from the functional complexity, so the user doesn't have to learn new rules in order to use new features. Note that this is not an interface-level problem. If the functional logic is hard to use, the best interface in the world won't make the product easy to use. One strategy is to apply appropriate metaphors at the level of the product's logic, rather than just the interface. We're used to thinking about metaphors in terms of what icons represent, how radio buttons and check boxes work, and so forth. But the principles of metaphors can be carried to the level of the logic and, ideally, applied across the entire range of product functions. In other words, make the product work like the user thinks, so the user doesn't have to learn how the product works.
The desktop metaphor of the Mac and Windows interfaces is a good example of this, because it re-defines the underlying functions of the operating system into a conceptual world that the user already knows. And it offers a way out of the functions/usability bind. After all, Windows is substantially easier to use than DOS was, but it's infinitely more functionally complex.
Saturday, February 24, 2007
Friday, February 23, 2007
PowerPoint Prototyping: an Introduction
I've had several occasions recently to develop quick prototypes of new display designs, and some small, focused usability evaluations of design options in cases where analysis wasn't able to resolve all of the outstanding questions or issues. I've found PowerPoint to be ideal for this, for several reasons:
- Its familiar graphics front end make developing the prototype graphics quick and easy. Although PowerPoint doesn't have as much graphic power as, say, Photoshop, the Format Autoshape dialog (right click on an object) provides more than enough control to create graphics that are precise enough for interface prototyping.
- Its hyperlink features make it possible to build what are essentially "screen shots", or slides of what the interface would look like in each possible state, and simulate navigating between them when the user selects the available options on each slide. The hyperlink features (accessed by the Action Settings dialog) include both mouse click events (go to the link when you click on the object) and mouse over events (go to the link when you simply move the cursor over the object). This makes it possible to simulate such things as highlighting individual options in drop-down menus when you move the cursor through the menu.
- Its Visual Basic for Applications (VBA) back end makes it possible to build in much more complex behaviors than would be supported just through hyperlinks. For example, a VBA subroutine triggered by an object can cause another object to change in some way. I'll show an example of this below.
- Furthermore, VBA can be used to record user actions and send them to Excel. In this way, a prototype can be turned into a desktop usability test, with user selections, what slide they were looking at, relevant prototype status variables, and time tags all captured automatically in Excel for easy analysis. This makes it possible to quickly develop a prototype that can be used to automatically capture user performance data such as how much time it took a user to make a decision or complete a task, and what errors or choices they made along the way.
- Because most people in business already have PowerPoint and Excel, designers and researchers can develop prototypes, usability tests, and experiments with tools they already own instead of having to buy special-purpose products. Furthermore, in some cases, the files for a study can be sent to the user/subject and run remotely on their own machines. This makes running a small study much more convenient than it otherwise might be.
Depending on the complexity of the interface being prototyped, the actual prototype can be developed in anything from a day to a couple of weeks, and an entire usability study can be accomplished in a few days or weeks. To illustrate this, I've built a small prototype of a clothes dryer control panel. You can download it from here. After downloading the file, open it and enable macros. Select slideshow mode, and select a cycle. You can select a new cycle at any time, and adjust the dryness level and overall cycle time. You can also select START and watch as the panel goes through an abbreviated dry cycle. When the cycle is done, or at any other time, select PAUSE/CANCEL to return to the starting condition. For reference, this prototype took me about a day to build.
Here's how the demo works: the controls and displays that do not change behaviors from slide to slide are all built on the master slide so they're always available. The time window contains a variable that is set by the cycle buttons and adjusted by the time adjustment buttons and the dryness level selection. By implementing these controls and displays on the master slide, the settings are stable from slide to slide. The cycle buttons themselves are implemented in the various slides to make it easy to change the embedded LED in each button with a new cycle selection. Although this could have been done in code, this was one case where simply drawing the graphic changes was easier than writing the code, and it's a nice illustration of how PowerPoint gives you several ways of doing something.
What's the point of all this? My major point is that you may already own all the tools you need to create truly rapid UI prototypes that can also serve as platforms for usability tests with objective human performance data. And you don't need to be a VBA expert to get started. You can look at the code in this prototype by returning to the regular view (exit the slide show) and selecting TOOLS, MACROS, VISUAL BASIC EDITOR. The VBA help files (select HELP and help contents, and navigate to PowerPoint Visual Basic reference) contain all the explanations and code examples you may ever need to build your own prototypes.
- Its familiar graphics front end make developing the prototype graphics quick and easy. Although PowerPoint doesn't have as much graphic power as, say, Photoshop, the Format Autoshape dialog (right click on an object) provides more than enough control to create graphics that are precise enough for interface prototyping.
- Its hyperlink features make it possible to build what are essentially "screen shots", or slides of what the interface would look like in each possible state, and simulate navigating between them when the user selects the available options on each slide. The hyperlink features (accessed by the Action Settings dialog) include both mouse click events (go to the link when you click on the object) and mouse over events (go to the link when you simply move the cursor over the object). This makes it possible to simulate such things as highlighting individual options in drop-down menus when you move the cursor through the menu.
- Its Visual Basic for Applications (VBA) back end makes it possible to build in much more complex behaviors than would be supported just through hyperlinks. For example, a VBA subroutine triggered by an object can cause another object to change in some way. I'll show an example of this below.
- Furthermore, VBA can be used to record user actions and send them to Excel. In this way, a prototype can be turned into a desktop usability test, with user selections, what slide they were looking at, relevant prototype status variables, and time tags all captured automatically in Excel for easy analysis. This makes it possible to quickly develop a prototype that can be used to automatically capture user performance data such as how much time it took a user to make a decision or complete a task, and what errors or choices they made along the way.
- Because most people in business already have PowerPoint and Excel, designers and researchers can develop prototypes, usability tests, and experiments with tools they already own instead of having to buy special-purpose products. Furthermore, in some cases, the files for a study can be sent to the user/subject and run remotely on their own machines. This makes running a small study much more convenient than it otherwise might be.
Depending on the complexity of the interface being prototyped, the actual prototype can be developed in anything from a day to a couple of weeks, and an entire usability study can be accomplished in a few days or weeks. To illustrate this, I've built a small prototype of a clothes dryer control panel. You can download it from here. After downloading the file, open it and enable macros. Select slideshow mode, and select a cycle. You can select a new cycle at any time, and adjust the dryness level and overall cycle time. You can also select START and watch as the panel goes through an abbreviated dry cycle. When the cycle is done, or at any other time, select PAUSE/CANCEL to return to the starting condition. For reference, this prototype took me about a day to build.
Here's how the demo works: the controls and displays that do not change behaviors from slide to slide are all built on the master slide so they're always available. The time window contains a variable that is set by the cycle buttons and adjusted by the time adjustment buttons and the dryness level selection. By implementing these controls and displays on the master slide, the settings are stable from slide to slide. The cycle buttons themselves are implemented in the various slides to make it easy to change the embedded LED in each button with a new cycle selection. Although this could have been done in code, this was one case where simply drawing the graphic changes was easier than writing the code, and it's a nice illustration of how PowerPoint gives you several ways of doing something.
What's the point of all this? My major point is that you may already own all the tools you need to create truly rapid UI prototypes that can also serve as platforms for usability tests with objective human performance data. And you don't need to be a VBA expert to get started. You can look at the code in this prototype by returning to the regular view (exit the slide show) and selecting TOOLS, MACROS, VISUAL BASIC EDITOR. The VBA help files (select HELP and help contents, and navigate to PowerPoint Visual Basic reference) contain all the explanations and code examples you may ever need to build your own prototypes.
Thursday, February 22, 2007
Displays vs. Controls
Situation awareness has been a significant focus area for human factors over the last twenty years or so. I suspect that much of the emphasis on SA can be traced to Earl Wiener's finding, in the early studies of flight deck automation, that one of the most common questions in the flight deck was "what's it doing now?" The importance of SA has since been reinforced by the apparent causes of accidents in some automated aircraft. For example, the first three of the A320 accidents that occurred shortly after its introduction involved very experienced flight crews losing track of basic, fundamental aspects of the flight: airspeed, altitude, vertical speed, energy, etc. I think it's unlikely that an experienced pilot would ever lose track of any of these parameters in an older, non-automated aircraft, so SA certainly seems to be the important issue when it comes to managing highly automated, safety-critical systems.
But is it really the most important issue? Is "what's it doing now" really the most important question?
What causes a human error-related accident in the first place? Is the root cause a failure to notice what the system is doing? Or is it instead an input error that causes the system to enter an undesired, unexpected state? If it weren't for the initial error, would it be so important to notice what the system is doing?
I'd like to suggest that the question, "How do I get it to do what I want it to do?" is actually more important than the question, "What's it doing now?" After all, the failure to accurately communicate intent to the system is what causes the undesired state in the first place. An ounce of prevention is worth a pound of cure; in this case, getting the system to do what you want it to do is prevention, and figuring out what it's doing is the hoped-for cure. Ultimately, I think that SA to detect the error is less important than preventing the error in the first place.
Unfortunately, I think that we, as a community of designers, engineers, human factors people, etc. have put a disproportionate amount of emphasis on SA at the expense of helping the user avoid input errors in the first place. For many people, human factors is synonymous with "displays", and controls are taken for granted. Perhaps that's why a modern airplane has big, beautiful, high bandwidth displays with which to communicate to the pilot, and the pilot has knobs, buttons, and a relatively primitive keyboard with which to communicate to the airplane.
I once counted up the number of papers presented at the Human Factors and Ergonomics Society annual meeting that dealt with displays and compared them with the number that dealt with controls. The display-related papers outnumbered the controls-related papers by about five to one. I then did the same exercise for the International Symposium on Aviation Psychology; there, there were 159 papers related to displays and 6 related to controls.
I suspect that the same thing may be true in product design. Designers seem to pay a lot of attention to the formatting and appearance of displays, but assume that the user will learn whatever control logic is provided. Hence, we're stuck with alarm clocks whose alarms we can't figure out how to shut off, car radios we can't figure out how to program, etc. And if you think of it, I'll bet that when people have difficulty figuring out how to use a product, it's probably because they're hung up on how to get it to do what they want it to do, rather than trying to figure out what the product is actually doing.
There's one other reason that I think input logic is more important than SA: since people often see what they expect to see, what they thought they did affects what they think the system will do. When pilots select the wrong flight control mode, they may miss all the visual indications that the mode is wrong because they "know" what they told the airplane to do, and they interpret what they see in light of that expectation. Again, the input error is the root cause and SA, at its best, can only catch the original error, but the error and its departure from the user's expectations hampers subsequent SA.
In the interests of preventing such errors in the first place, I'd like to suggest that we start placing more emphasis on controls and input logic, instead of devoting so much attention to SA. We need to make functional logic more intuitive, less complex, and less error-prone. We need to start applying all the cognitive science we've been doing for the past thirty years to control use. Again, an ounce of prevention....
But is it really the most important issue? Is "what's it doing now" really the most important question?
What causes a human error-related accident in the first place? Is the root cause a failure to notice what the system is doing? Or is it instead an input error that causes the system to enter an undesired, unexpected state? If it weren't for the initial error, would it be so important to notice what the system is doing?
I'd like to suggest that the question, "How do I get it to do what I want it to do?" is actually more important than the question, "What's it doing now?" After all, the failure to accurately communicate intent to the system is what causes the undesired state in the first place. An ounce of prevention is worth a pound of cure; in this case, getting the system to do what you want it to do is prevention, and figuring out what it's doing is the hoped-for cure. Ultimately, I think that SA to detect the error is less important than preventing the error in the first place.
Unfortunately, I think that we, as a community of designers, engineers, human factors people, etc. have put a disproportionate amount of emphasis on SA at the expense of helping the user avoid input errors in the first place. For many people, human factors is synonymous with "displays", and controls are taken for granted. Perhaps that's why a modern airplane has big, beautiful, high bandwidth displays with which to communicate to the pilot, and the pilot has knobs, buttons, and a relatively primitive keyboard with which to communicate to the airplane.
I once counted up the number of papers presented at the Human Factors and Ergonomics Society annual meeting that dealt with displays and compared them with the number that dealt with controls. The display-related papers outnumbered the controls-related papers by about five to one. I then did the same exercise for the International Symposium on Aviation Psychology; there, there were 159 papers related to displays and 6 related to controls.
I suspect that the same thing may be true in product design. Designers seem to pay a lot of attention to the formatting and appearance of displays, but assume that the user will learn whatever control logic is provided. Hence, we're stuck with alarm clocks whose alarms we can't figure out how to shut off, car radios we can't figure out how to program, etc. And if you think of it, I'll bet that when people have difficulty figuring out how to use a product, it's probably because they're hung up on how to get it to do what they want it to do, rather than trying to figure out what the product is actually doing.
There's one other reason that I think input logic is more important than SA: since people often see what they expect to see, what they thought they did affects what they think the system will do. When pilots select the wrong flight control mode, they may miss all the visual indications that the mode is wrong because they "know" what they told the airplane to do, and they interpret what they see in light of that expectation. Again, the input error is the root cause and SA, at its best, can only catch the original error, but the error and its departure from the user's expectations hampers subsequent SA.
In the interests of preventing such errors in the first place, I'd like to suggest that we start placing more emphasis on controls and input logic, instead of devoting so much attention to SA. We need to make functional logic more intuitive, less complex, and less error-prone. We need to start applying all the cognitive science we've been doing for the past thirty years to control use. Again, an ounce of prevention....
Wednesday, February 21, 2007
New Human Factors Blog
Welcome to my human factors and user-centered design blog. I am a human factors consultant with 25 years of experience in human factors research and design, and I want to use this blog to share thoughts, lessons learned, tools, and best practices with anyone grappling with usability questions and challenges. Some of the topics I intend to cover include the following:
- Many product designers and researchers are looking for convenient, easy-to-use, flexible, and inexpensive rapid prototyping tools. If you have Microsoft Office, you already have the basic tools you need to set up your own portable prototyping environment and usability lab. Did you know that PowerPoint can serve as a very capable rapid prototyping platform, and that with a little Visual Basic for Applications code, you can capture user selections along with time tags and send them to Excel for automated recording of user performance data? I'll describe how to do this in a series of posts.
- I believe that most usability problems associated with electronic products are not due to poor user interface designs, but rather to poor functional logic. In other words, the problem is not typically how the product looks and feels, but rather how it works underneath the interface. If the functional logic is hard to learn and remember, the best UI in the world isn't going to make the product easy to use. I'll discuss some of the usability issues related to functional logic and how to address them.
- The design is only as good as the requirements, and the requirements are only as good as the analysis. I'll present a number of analysis methodologies I've developed and found useful on various projects. Furthermore, the requirements themselves may have an optimal structure in a human-centered process. Using a hierarchy of mission requirements, operational requirements, functional requirements, information requirements, and display/control requirements, along with the appropriate analysis methods for each stage, can help resolve many, if not most, design problems and issues before the design itself is even begun.
- Usability practitioners often debate the merits of expert design reviews vs. formal usability testing, and there's been some research on which is better, or at least more appropriate, for different problems and stages of design. There's a third option: design analysis tools. These can range from checklist-like forms to computer-based tools that apply heuristic reasoning to diagnose interface design problems that may lead to specific kinds of error. This is particularly useful because errors are often hard to produce and observe in the lab. Structured usability analysis tools are a particular interest of mine, and I intend to devote a lot of attention to them.
If any of these topics is of particular interest to you, please let me know and I'll delve into it/them first. I always welcome comments and questions. You can post comments here, or email me at vic@uird.com. If you'd like to learn more about me and our services, please visit my (very simple) web site at www.uird.com.
Thanks for reading -
Vic Riley
- Many product designers and researchers are looking for convenient, easy-to-use, flexible, and inexpensive rapid prototyping tools. If you have Microsoft Office, you already have the basic tools you need to set up your own portable prototyping environment and usability lab. Did you know that PowerPoint can serve as a very capable rapid prototyping platform, and that with a little Visual Basic for Applications code, you can capture user selections along with time tags and send them to Excel for automated recording of user performance data? I'll describe how to do this in a series of posts.
- I believe that most usability problems associated with electronic products are not due to poor user interface designs, but rather to poor functional logic. In other words, the problem is not typically how the product looks and feels, but rather how it works underneath the interface. If the functional logic is hard to learn and remember, the best UI in the world isn't going to make the product easy to use. I'll discuss some of the usability issues related to functional logic and how to address them.
- The design is only as good as the requirements, and the requirements are only as good as the analysis. I'll present a number of analysis methodologies I've developed and found useful on various projects. Furthermore, the requirements themselves may have an optimal structure in a human-centered process. Using a hierarchy of mission requirements, operational requirements, functional requirements, information requirements, and display/control requirements, along with the appropriate analysis methods for each stage, can help resolve many, if not most, design problems and issues before the design itself is even begun.
- Usability practitioners often debate the merits of expert design reviews vs. formal usability testing, and there's been some research on which is better, or at least more appropriate, for different problems and stages of design. There's a third option: design analysis tools. These can range from checklist-like forms to computer-based tools that apply heuristic reasoning to diagnose interface design problems that may lead to specific kinds of error. This is particularly useful because errors are often hard to produce and observe in the lab. Structured usability analysis tools are a particular interest of mine, and I intend to devote a lot of attention to them.
If any of these topics is of particular interest to you, please let me know and I'll delve into it/them first. I always welcome comments and questions. You can post comments here, or email me at vic@uird.com. If you'd like to learn more about me and our services, please visit my (very simple) web site at www.uird.com.
Thanks for reading -
Vic Riley
Subscribe to:
Posts (Atom)
Posts
