It's Not Your Software (Continued)

Getting to the real heart of the issue, Platt asked how many in the audience drive a car with a stick shift, and it looked as if nearly every person in the auditorium raised a hand. Guessing that at least three quarters of the audience thought that a manual transmission controlled with a stick shift—something that is harder to learn, harder to use, but gives you better control—is a good trade-off, Platt contrasted this result against the roughly 12 to 14 percent of automobiles sold in the U.S. that come with stick shifts.

"Six out of eight think something that's harder to use but gives you better control is a good trade-off; only one out of eight of the general populace thinks that's a good trade-off. Normal people do not drive stick shifts," Platt said emphatically. "Why? Because they don't care about the driving process in and of itself. It's a means to an end. They don't want to drive somewhere; they want to be somewhere."

Following an outburst of laughter from the audience, Platt evoked a loud round of applause by punctuating the theme: "It's an important distinction. You think your users want to use your software. They do not want to use your software. They want to have used your software."

Proof in the Pudding The essence of Platt's message was simply "we need to make it just work," and he launched into several colorful and funny examples to demonstrate how much thought—or lack of it—went into the user's perspective when designing some of the popular software that many use every day.

For instance, beginning with Microsoft Word Platt admitted how he sometimes overshoots "by a few pixels" when selecting the File menu on the main menu bar and ends up dragging it around the screen until it ends up floating over text. Expressing his disgust with this "moveable menu bar" feature, he described the inconvenience of having to stop what he's doing two to three minutes to drag it back, redock it, and then curse "the ancestry of the moron who thought of this feature."

While it might not sound like much, Platt said, a couple of minutes per day wasted and factored by half a billion users equates to wasting "virtually 72 human life spans every single day with this thing!

"Have you ever seen or heard of even one single person ever in the entire history of the universe that has wanted to take the menu bar and dock it on the left-hand side of the program, or the right-hand side, or leave it floating? No," Platt said.

In contrast, Platt did say that Microsoft Word's autocompletion/autocorrect feature is an example of something the application does very well. "This program is doing what computers do well," he said. "It's being rigorous, it's being thorough… it's doing what computers do well so that people can do what they do well. Instead of making people think more like computers, instead of making people adjust themselves to programs, which is kind of what the first example is, here the program is adjusting itself to what people do, and the humans can be more human and work like a computer. This [feature] is a really good design; the guy who thought this one through did a really nice job."

Platt offered another example of good design that is demonstrated when you first arrive at Google's Web site and the thought that went into what their users do. If you enter Google's address from another country—Platt used Sweden as an example—the home page will display automatically in Swedish, since the address was entered from a location in Sweden. Further, if an English-speaking person in Sweden types the address, that is, if the program "guessed wrong," for that particular user, Google provides a readily identifiable, easily accessible link that allows the user to refresh the page in English.

Later, after disparaging the Web site design for a leading, worldwide shipper based on the way that site handles a similar user-location feature, Platt generated a burst of laughter when he demonstrated Google's ability to track a package by tracking number much more quickly and efficiently than the shipping organization's Web site was able to do.

Make It Just Work To implore his audience to consider the user's perspective when it comes to software design, Platt offered five salient points that are necessary to make software "just work":

1. Add a virgin to the design team. Platt said the design team should have someone involved that doesn't know the implementation of the software. Frequently, software tends to be designed with user interfaces that expose the internal workings of the program directly to the user, forcing the user to understand how the program is written internally. By example, Platt contrasted the way in which Notepad asks users if they want to save changes to a file before exiting against applications such as Microsoft Money or Quicken that move completed checking data automatically to a check register without asking users if they want to save it. As Platt put it, the act of entering the data means, "yeah, I put the data in. Why are you asking me this? If I wanted to throw away the data I would. It's nice to have the undo capability, to say, 'yeah, just throw it away.' But most of the time the user wants to save the data, and that should be the default."

2. Break convention when needed. Platt said that just because something was done the old way doesn't mean that it's necessarily a good way.

3. Don't let the obscure features get in the way of the main features. Here he used Starbucks.com's store locator feature as an example. Typing a zip code to search for a nearby Starbucks can sometimes produce a "No stores found" error that includes the suggestion of increasing the area range or proximity, in miles, to better the user's chances of finding a location in a subsequent search.

   Platt termed this kind of feature "silliness" because first you have to find the search radius and ask yourself if that is the same as the proximity. All the user wants to do is to find the nearest Starbucks, he said, and the fact that the proximity selector gets in the way is really bad design.

   "Perhaps the Starbucks programmers thought that this was cool and wonderful that they were putting in this additional capability of specifying the range," Platt said. "A lot of edge cases complicate the mainstream, and that's bad design."

4. Instrument your application very carefully. Here, Platt suggested trying usability testing to see how the user interacts with the application. He said it's hard to find out what the "silent majority" thinks, and hard data is the most useful means to carefully think through instrumentation.

5. Consider whether design decisions are taking you closer or farther away from the software just working. In addition to priming attendees with heavy doses of laughter prior to the Jolt Awards ceremony, Platt certainly gave them a lot to think about when it comes to considering the needs of the user, and not the developer, when designing software.

About the Author
Terrence O'Donnell is a senior editor with the 1105 Redmond Media Group.