User Fiendly

No, that title is not a typo. If you didn't think it was, look again. If you noticed, you may not be surprised that my topic is voice response systems.

I can always tell when my wife is negotiating a company's telephone system's speech recognition menus by the note of restrained frustration in her voice. I thought of this when I answered a call from Verizon Wireless wanting to survey me about their own voice response system for customer service. The first question was, "Did you use the voice response system, or did you choose to use the telephone keypad?" When I said, "Telephone keypad," that was all they wanted to know.

For at least several decades now, clueless executives have somehow been under the impression that speech recognition is the magic bullet that will make all technology approachable and user friendly. Nothing could be further from the truth. Remember when the same magical qualities were attributed to GUI's? A thousand graphical interfaces ensued that were just as hard to use as DOS or UNIX.

The key point that I think these people miss is that it's not the form of the interaction (text, graphical, key presses, voice), but rather what you do with it. The intuitive nature of the graphical interface derives from the use of appropriate metaphors; the graphics simply enable a broader range of possible metaphors than is allowed by a command line interface. Similarly, speech recognition does not itself make a system easier to use - it can actually make it much harder to use. What matters is what you do with it.

On this point, a fully functional and reliable natural language system would be ideal. Lacking that, a constrained, limited vocabulary is second best, but still probably slower and therefore less desirable than simple key presses. An open-ended, pseudo-natural language interface that sometimes works and sometimes fails in unpredictable ways, doesn't react appropriately to expressions of frustration, and gets in the way instead of greasing the skids is the worst possible solution. Yet that's the one we have now. So why, exactly, do companies think this is easier than pressing keys?

Blame the User

“Oh, come on,” Richard said quietly to himself.

“Sorry?” Bill, or Bob, or whatever lifted his head from behind Richard’s monitor.

“Sorry, not you,” Richard said. “It’s this stupid magazine. Everyone’s blaming the financial industry for the subprime mess, but what about the home buyers? Why doesn’t anyone make them take responsibility for signing up for loans they couldn’t repay?”

“Good point, sir.” Bob or Bill put his head back down and tapped some more keys.

“How much longer, anyway?” said Richard.

“It’ll be another hour or so. Um, did you change any of the settings on your anti-spyware utility?”

“Oh, I don’t know. Maybe. It was running real slow so I changed a bunch of settings in various places until it sped up. Why?”

Bill or Bob sighed. “Well, you’ve got a major spyware infestation, including several stealth keyloggers installed by Trojans. They’ve probably captured all your passwords and account settings. Do you access the company trading accounts from this machine?”

“Sure, I have to. So, what do you have to do?”

“Well, sir, you should probably make sure there haven’t been any unauthorized transactions from your account. In the short term, I can get you up and running but I’ll have to reformat your drive and reinstall Windows. You’ll lose all your files, but your computer will be up again. I may be able to restore your files from backup but I’ll have to make sure they’re clean.”

“OK. Whatever.” Richard went back to his reading while his computer made the Windows shutdown and startup noises several times in a row. Finally, he folded the magazine and hurled it across the room, neatly hitting the rim of his wastebasket and knocking it over. “Damn. You’d think people would know better than to sign false income statements. I just don’t get it.”

He pondered for a few more minutes. Then, “If people aren’t going to be responsible, how do you keep it from happening again?”

Bob or Bill looked up and hesitated for a moment. “Well, sir, if it were up to me, I wouldn’t let anyone use a computer unless they knew what they were doing.”

Feature Creep

I've often heard users and designers bemoan "feature creep" and express the wish that manufacturers would limit the number of features supported by their products in order to make them more simple to use. While I sympathize with the goal, I don't think that avoiding feature creep is necessarily the solution.

Consider the iPod. A recent issue of MIT's Technology Review magazine (May 2007) focused on design, and frequently held up the iPod as a design ideal. Don Norman, speaking of Apple in general, stated, "The hardest part of design, especially consumer electronics, is keeping features out." Mark Rolston, senior vice president of creative at Frog Design, said, "The most fundamental thing about Apple that's interesting to me is that they're just as smart about what they don't do. Great products can be made more beautiful by omitting things."

So, back to the iPod. It originally began life as a music player. Along the way, it added a calendar, contacts, notes, alarm clocks, world clocks, stopwatch, audiobooks, picture viewer, video, podcasts, and games, and it can be used as an external hard drive, even a bootable one for an OS X machine. The iPod Touch adds internet surfing, a You Tube viewer, online access to the iTunes music store, and the ability to buy whatever song you're currently hearing at Starbuck's.

Hmmm... Isn't this the very definition of feature creep?

And yet, the iPod remains beloved, an icon of good design. And very deservedly so.

Because what makes the iPod easy to use is not feature restraint, but rather the fact that all of its many features work the same way. The user need only learn one general rule about how the interface works and can apply that rule to pretty much every function.

So perhaps the trick isn't in avoiding feature creep, but rather in avoiding "rule creep".

Six Sigma, Innovation, and Usability

This week's (June 11, 2007) Business Week cover story is about how Six Sigma "almost smothered" 3M's culture of innovation. The gist of the story is that 3M's attempt to use Six Sigma in every corner of its operations, including R&D, caused innovation to become more incremental, more safe, and more saddled with administrative overhead. Consequently, higher risk programs weren't pursued and 3M has slipped markedly in measures of innovation, such as the proportion of revenues coming from recently developed products.

Having been through a Six Sigma transformation at a large organization, I have a few thoughts on this.

First, it seems to me that user experience is one of the most important and least appreciated aspects of quality. As a proponent of applying more structured methods to user requirements and usability assessment, I think that formal user requirements methods and structured usability testing fit right in with the spirit of Six Sigma and other quality programs. If Six Sigma, for example, causes an organization to move from focus groups to more effective human performance-based measures of usability, I'm all for it. I hope that anyone advocating for Six Sigma within an organization will recognize that user experience and usability are key aspects of quality and deserve the rigor and emphasis traditionally paid to engineering and manufacturing.

Second, I think that everyone should learn something about statistics. I think that some understanding of probability and statistics is actually necessary in order to not only work effectively, but also to make informed decisions in most aspects of life, including voting. When an organization adopts Six Sigma and makes everyone learn the basics of statistical analysis, everyone benefits, including society at large.

However, no program dedicated to process improvement should itself become a process impediment, and the indiscriminant application of Six Sigma to all parts of an organization has a lot of potential to do just that. It's well understood that many of the most profitable break-through products come from serendipitous discoveries enabled by exploratory research that may not be undertaken in a risk-averse, highly controlled environment. This is what the Business Week article focuses on.

To me, the benefits and drawbacks of Six Sigma all stem from the same source: the fact that Six Sigma tries to substitute objectivity for subjectivity and data for intuition wherever possible. I think this is both useful and appropriate in some applications, such as administration, logistics, and manufacturing, but not so much in R&D. Research and design, particularly the exploratory types that lead to breakthrough products, depend to a large extent on subjectivity and intuition and are easily stifled by processes that seek to drive them out.

Furthermore, even where it's useful and appropriate, Six Sigma can still fall down because it's very susceptible to garbage-in/garbage-out. In Design for Six Sigma, for example, people often have to enter ratings of competitive position and other market environment factors into an analysis process, and these form the basis for subsequent decisions. Many of these factors can't be directly quantified or measured and must necessarily be subjectively estimated. Lengthy analysis processes can often include chains of subjective judgments, and small errors in early steps can compound into much larger errors at the end. It very easy, in Six Sigma, to end up with a product that looks like fact or data but is actually largely fiction, because of the use of formal methods to force subjective products into an apparently objective framework.

The bottom line, I think, is that Six Sigma and other quality programs can be very useful and productive if used within their valid limits, but can be highly counterproductive otherwise.

PowerPoint Power Tip # 1

Need to delete or change an object that's being covered by another object that you don't want to move or delete? Click and drag over both objects to select them both, then hold the Shift key while you click on the objects. This should de-select the object in front, since that's the one that will intercept the click. Now you should have only the object behind selected; you can now delete it, move it using the arrow keys, or whatever else you want to do with it.

The Right Answer

One of our friends here recently sent out a flyer on behalf of the local historical society asking people to submit their stories of how they learned about Point Roberts and how they got here. The flyer also asked people to donate $10 to the society. Unfortunately, the wording of the flyer made it appear that people had to donate in order to submit their stories, and the wording of the request for stories was so open-ended that some of the responses were unusable.

A university student was wrestling with the design of an experiment. She knew the general topic to be investigated and had a general approach in mind, but couldn't arrive at the specific approach or the steps that needed to be taken.

A group of engineers at a company I worked with were trying to design an input device for a workstation. They were trying out several options and having a hard time deciding which one was the best.

These situations all have one thing in common: inadequately defined requirements. I think this is one of the most common mistakes made by designers of every type, and I think it stems partly from a tendency to think one already knows all the requirements, or that the requirements are obvious and don't need to be spelled out. But my friend at the historical society might have had a better response if he had first spelled out what the desired product was (a specific type of story and a willingness, separate from the story, to make a donation), the student would have had an easier time designing the experiment if she had articulated the experimental question to be resolved, and the team of engineers would have been better able to decide which design was best if they had specified some criteria first.

You may think this goes without saying, but I can't count the number of meetings I've been in that have gone either nowhere or in circles until someone said, "What are the requirements?" Perhaps it's one of those lessons that are so basic that we need to be reminded of them continually, because we take them for granted otherwise. And, as illustrated by these three situations, I think this lesson goes beyond product or interface design to life in general. After all, how do you know what the right answer is if you haven't defined the requirements?

New Term...

...for a poorly designed interface: "untuitive".