October 20, 2004
You Are Not Your UsersPay close attention to what users say and do during the application testing process.Douglas Reilly, Access Microsystems Inc.
The successful creation of an application requires software developers to pay attention to what their users say and do during the testing process.
Recently, I was at the Microsoft Mobilized Developers Conference (MDC) where David S. Platt (author of The Microsoft Platform Ahead) spoke about the Pocket PC Phone and why it might not set the world on fire despite the fact that most of the developers at the conference thought it was very cool.
By way of example, he asked for a show of hands of those people at the conference that drove a car with manual transmission. Perhaps 40 percent of the crowd raised their hand. He then asked how many did not drive a car with manual transmission, but would if their spouse/significant other would let them. I would guess an additional 20 percent of hands went up. He then reminded us that in the U.S., only about 10 percent of cars are sold with manual transmissions. So, when it comes to drivers, we developers at that conference were not even remotely representative of the general population. He perfectly crystallized this example by saying, "You Are Not Your Users!" Adventures in User Testing This is not the first time I realized this fundamental fact. Many years ago, I was fortunate to work on a project where I was creating a computerized employment selection program to hire typists. At the time, most typing was still done on electric typewriters, and so we needed to validate the test to ensure that good typists, regardless of computer skills, performed well on the test. To do this, we went to various secretarial schools and gathered up a number of typists and then tested them on the typewriter and our test program. We developers observed some of their activities through a one-way mirror. We had screens that explained the Page Down and the Page Up key. When the test applicants reached the page down screen, they pressed Page Down to get to the next screen, as instructed. On the next screen, the Page Up screen, we watched as the first applicant, rather than pressing Page Down to continue, instead pressed Page Up and got to the Page Down screen. We developers found this very amusing. The last laugh, however, was on us, as other applicants did exactly the same thing. Not every applicant, but perhaps 30-40 percent of them, would press Page Down, then Page Up, then Page Down as long as we could stand it. This was a problem that we would never in a million years have discovered on our own. It made no sense to any of us to hit Page Up and Page Down repeatedly. We were used to looking for instructions on the status bar, and the instructions on the status bar of the Page Up screen clearly explained that Page Up would bring you to the previous screen, and Page Down would bring you to the next screen. We were clearly not our users. Some of these people had never worked on a computer before (recall this was back in the late 1980's). We developers had all been using computers for many years. The answer here was a simple wording change, along with a configuration change that disallowed the Page Up key on the Page Up screen. Subsequent tests showed no users even trying to Page Up and Page Down from screen to screen. The same issues arose many years later as I installed my first significant intranet application. Many of the users had never used the Internet, and so the Web application that was so transparent for me to use was daunting to my users. What is a hyperlink? When should you use the Back button, and when is that a problem? Again, these were problems we did not anticipate. At the time, we presumed that folks would be a bit familiar with a Web interface; however a significant percentage were not. The users in this case were used to using a "glass teletype" application, and so even a traditional Windows application would have been a stretch. Once again, a few wording tweaks and some interface clarifications did the trick, and the application is still working to this day. These days, using a Web interface is likely to be easier for users. Users are very accustomed to using Web sites—even my mother and mother-in-law are very used to the Internet. Still, there are issues, and not all applications will be Web applications. And as mobile developers, we can presume that many users of our applications will be new to the form factor we are targeting, be it Tablet PC, Pocket PC or Smart Phone. The User Interface Test Matt Hawley blogs about "The Girlfriend Test." This is a good start at usability testing, though not sufficient. I often have my wife or children look at my applications while I watch them work. In general, my children are more adventurous when exploring a user interface, but even they have been occasionally stumped by a user interface component. More than the ability to simply perform the operation is observing how much difficulty is involved. For instance, it was common in Classic Active Server Page (ASP) applications to use a list box that allows multiple selections. You select one item, and then you can Control-Click to select additional entries, or Control-Click to select a range of entries. I find this reasonably convenient and use these same selection techniques all the time in Windows Explorer and other applications. I have been horrified to see that even some of the developers at some of the client companies I work for have difficulty successfully using this sort of selection. I have changed applications in ASP.NET to use the new CheckBoxList control, which provides an interface as shown in the figure below:
Would anyone have a tough time doing multiple selections? Perhaps, but far fewer than would have difficulties using a list box and Shift and Control clicks. Just as important, it is unheard of for users to be a member of more than a couple of groups. Here again, however, there are times to violate the rules of "Usability" in order to make the application really usable by your target audience. For instance, in the figure above, there are only seven entries. Even if your user needs to select all seven—that is seven clicks—it's not that much more difficult than doing the shift-clicks required to select all. Just as important, setting up users is a reasonably rare operation in this application, and so ease of use is perhaps more important than overall ease of operation.
|
|
|||||||||||||||||
|
|
|
|