Software and hardware developers must be careful not to make incorrect assumptions regarding the needs of their targeted users. IBM made this mistake when designing its Trackpoint II pointing device, and then could not figure out why users preferred the Trackpoint after a ‘turbo’ mode was included. In IMS’s experience, the turbo mode caused pointers to accelerate abruptly when a threshold value was exceeded by the pressure on the stick. As it turned out, users preferred the turbo mode because it allowed them to make the rapid Trackpoint movements frequently required in their work: turbo mode enabled them to switch quickly from one application to another, a key operation not reflected in IBM’s initial tests. This scenario reflects two mistakes made on the part of IBM: they had a myopic view of how developers work, and they treated users as single-tasking workers.
Earlier this month, I spent some time at a hardware conference called “Portable by Design.” One of the most interesting sessions was a history of IBM’s Trackpoint II pointing device — the pressure-sensitive joystick that distinguishes IBM’s laptops.
That history bears some lessons for software developers. You see, at one point the IBM folks were trying to figure out why users liked the Trackpoint II better when IBM added a “turbo” mode to its software. This made the pointer accelerate abruptly when the pressure on the stick exceeded a threshold value.
This user preference didn’t seem to make sense, because IBM’s earlier research had found that the worst thing you could do for quick and accurate selection was to let the pointer move faster than the eye could track it. In the performance tests that IBM was using, which measured speed and accuracy of pointing and selection tasks, adding the turbo mode did not produce an improvement.
But users doing real work definitely liked the turbo prototype better.
The performance tests ignored one of the actions people most often perform with a pointing device when using a GUI. One of their most frequent operations, not reflected in the initial tests, was switching from one application to another. This required not precise placement, but rather a rapid movement to some point — any point — in another window so the user could click the button and bring that window to the foreground. The turbo mode made this much easier to do.
So the IBM tests, initially, made two mistakes — errors that may be common in developing applications, as well as in designing intuitive hardware. First, they had a “micro” vision of ease of use that focused on details, such as clicking on a button or selecting a word. They neglected, at first, the “big picture” task of selecting the window in which to be working.
Developers make a similar error when they make the individual features of an application work well, but fail to take a big step back and look at how everything fits together. When a user is constantly thinking, “There must be some way to do this — where did they hide it,” that’s a symptom of this error. Users who have to make frequent trips to the menu bar, or navigate through different branches of the menu tree to do commonly grouped operations, grow frustrated and annoyed.
You can prevent this problem by providing intuitive groupings of features into dialog boxes rather than separate menus, and by creating “multipath” designs that let you access a feature from a button in a dialog box — when that makes sense — as well as from a menu of its own.
And don’t forget, even simple things, such as the name of a menu, can have measurable impact on users’ task performance. For example, I recall a video from Microsoft’s usability labs that showed users finding “Options” much more quickly than “Preferences.”
I said that IBM’s testers had made two errors. The second one was that of treating users as single-tasking. If the testers had thought of multitasking as a feature of users, as well as of operating systems, then task switching would surely have been considered in their tests.
Your applications should also consider the multitasking user by fitting into the other chores that make up a work day. This means, among other things, cooperating with other tasks in non-preemptive environments such as Windows and the Macintosh.
Do this well and you can build more than a usable application. You can create an all-day environment for happy users — who’ll spread the word.