Wednesday, September 16, 2009

More isn’t better, but (help me with) Something Else is

Sometimes it occurs to me that we designers have tools in our toolbox that we use trustingly but haven’t explained why to others. Such a tool is usually rightfully worthy of our use and trust, but should be accompanied by sound theories and reasons. To that end, I thought I’d spend a little time on the origins of the VUI design component “help me with something else” and its variants.

Ideas around it first began back in 2000 or so on a project at Intervoice for a British Columbian transit company. We were designing a menu of options and were dissatisfied with the in vogue wording used to point to choices that were on a secondary menu. I.e.:

“You can say ‘plan a trip’, ‘get a schedule’, ‘paratransit’, or ‘more options’.”

That sort of phrasing seemed to be clunky and out of character for the design feel we wanted to deliver and we just felt it was inadequate for callers to latch onto.

In an informal discussion, one of my team members said “we need something else”, referring to the current choices being used in the design world, such as “more choices”, “other”, “none of those”, etc. When he said that, we looked at each other and said, “why not try ‘something else’ in the prompt?” So we began thinking about this:

“You can say ‘plan a trip’, ‘get a schedule’, ‘paratransit’, or ‘something else’.”

We liked where that was going, but quickly thought of a semantic problem in that the instruction seemed not to refer so much to additional choices but rather to telling the caller that they could say just about anything else. That, of course, was not the case and would cause interaction issues. Plus, the phrase seemed overly ambiguous, maybe even more so than “more options”. So after a bit of round-and-round about it, we determined that we wanted to try the phrase “help me with something else” (HMWSE).

“You can say ‘plan a trip, ‘get a schedule’, ‘paratransit’, or ‘help me with something else’.”

Though it might seem pedestrian now, this was a pretty novel idea at that time. The “more options” construction came directly from DTMF IVR menu structures, meaning it was deeply ingrained as the default presentation. Furthermore, in the early days of voice interaction design, there was an emphasis on pithy phrasing and HMWSE seemed like a mouthful. However, it had several strong characteristics that appealed to us. It was clear, used more common wording, and we actually heard similar phrasing in everyday conversations around us.

Fate, though, had other plans then. For a couple of reasons, we weren’t able to use the idea in that current design. But I held on to it for several years and finally had the opportunity to try it out again in 2004 at Voice Partners. We were working a significant redesign for a mobile carrier’s customer service line. As you can imagine, there were many functions for callers to choose from in the application. As soon as I saw the struggle with how to represent the concept of other things the callers could choose, I suggested that we try out HMWSE. I walked through its origins and we had some good discussion about why we though it would work. So we tried it in usability testing in opposition to the traditional “more options” and it was then that the strongest reason for the superiority of HMWSE emerged.

As we watched and listened to participants move through and struggle with the menus, two patterns of behavior became clear around their decisions to access more choices. Many of those who used “more options” seemed to be exhibiting surfing behavior triggered by that phrase. That is, they wanted to hear and think about all possible choices before committing to one because “more options” seemed to mean “more options that you might want to hear before you make a decision”. This frequently led, though, to failures in the menus as callers encountered cognitive load problems having to hold all the choices and their possible meanings in mind. Callers who heard and used HMWSE, however, did not encounter nearly the same number of problems. They were not surfing but rather, and this is the key point, they were listening to and then rejecting previously heard choices when they said HMWSE.

“Help me with something else” allowed them to hear, absorb, then discard choices they did not consider valid and specify to the system that new choices should be presented.

This was a major eye-opener for me, and my co-designers. While we had suspected that HMWSE was better, we had discovered a solid cognitive reason for it. Callers clearly preferred not to surf, but to have a way to eliminate choices rather than play a guessing game. Thus, HMWSE became a new best practice for use when menus exceeded a certain length.

Failing menu: “You can say ‘my bill’, ‘my plan’, ‘technical support’, or ‘more options’.”

Winning menu: “You can say ‘my bill’, ‘my plan’, or ‘technical support’. You can also say ‘help me with something else’.”

Now, to be clear, all the other principles of good menu design still apply. Choices must be clear, unique, and aurally distinct, among others. HMWSE is not a ticket to allow “anything goes” menu construction. But, when used with a solid set of menu items that need to span more than one presentation instance, it is the best choice for letting callers know that if they do not hear what they want in the initial list, they have a clear way of indicating that they want to discard the first list and hear another.

“More Options” for HMWSE

In the several years since that discovery, the use of HMWSE has grown in two ways.

First, I’ve encountered situations where a variation of HMWSE works better than the original wording. Semantically the concept is the same, though. An example is:

“You can say ‘car’, ‘bus’, or ‘train’. You can also say ‘I need different transportation.’”

Additionally, we began using a variant of the idea with open-ended prompts. Until the last couple of years, the standard was to coerce the caller into saying anything at a “What are you calling about today?” type prompt in the hopes we could pin a meaning on it. However, many callers are just not sure what to do or what will happen and so are reluctant to give an actionable utterance. At Voice Partners, then at SpeechCycle, rather then “erroring” into a menu, we began very successfully using “what are my choices” and “give me some choices” as ways callers could specify that they preferred a menu over the open prompt. Such phrases allow caller choice and control versus locking them into a specific interaction method.

The other area of growth is a more widespread use beyond up-front menus where HMWSE can still mean “I don’t want any of those so give me different options”. Some examples are follow-up menus after tasks are completed, lists of items to select from, and lists of global actions. Again, as the previous area indicates, these additional contexts sometimes require variations on the wording.

A Note: SE <> HMWSE

One thing I want to be clear about is that the use of HMWSE is better than just offering callers the phrase “something else”. In the past couple of years, I’ve heard systems presenting simply “something else” in menus, and that’s a mistake for reasons mentioned above. It fails on a semantic level to be a clear instruction to obtain other menu choices and instead at best sounds like an invitation to say anything. I strongly discourage its use.

So, don’t be afraid to offer your callers a good range of choices in more than one menu. In HMWSE you have a tested tool to use for that. Yes, there is research that I consider valid that shows that menus with more than four or five items can work well. However, there are contexts in which doing so might not be the best approach. Because of that, HMWSE helps round out the set of tools to help create great voice interactions when offering choices to callers.

Tuesday, September 1, 2009

This can be the beginning of a beautiful friendship

An interesting thing about going to tech-oriented conferences that mix business managers and implementers is the tension between messages. There are often competing and conflicting voices promoting technology and customer (user) experience. The technology vendors publicize the latest new thing, the upgrade that brings it all together, and the surefire way to get more customers spending more money. The experience folks shout that whatever is to be done must be done based purely on customer need and desire; that user experience (UX) is all that matters.

Now, it's no secret which side I've been on in most of these public discourses. Though I've been on the tech side in some cases, mostly by far I've preached from the gospel of good experience. And in the situation that it's clear that moving toward a certain technology would harm customer experience, my position would be unwavering.

However, the primary argument and distinction is no longer valid and true to me. I now see these two as elements on a continuum. Even as elements to alternate during and maybe even between projects. They are interdependent, and maybe even codependent.

The way I see it, many of our advances in customer experience have relied on or been part of new technology or new use of existing technology. From the other side, technology relies on good customer experience for successful adoption. Look at Amazon during the emergence of the commercial web. And then there's everybody's favorite example, Apple's iPhone. Both involved a push forward in customer experience AND the use of technology. Neither would be as successful without the blend of both. And neither would be as interesting if one aspect won out over the other.

Where I'm going with this is to request a truce in the tech versus UX battle. Both are good and both are needed. Tech creators need to acknowledge that they need good UX design to win the hearts and hands of consumers. UX-ers need to acknowledge that good technology is needed to advance parts of our cause and that new (good) tech gives us a chance to shine.

Before the truce can be fully agreed to though, we have a little catching up to do in the basics. Too much technology, useful as it can be, has been put out there without the needed UX crafting to accompany it. Because of that, both the users (consumers) and the technology are getting short shrift. Users feel ignored and abused. The tech vendors are getting slammed for very correctable reasons. We need to stop the train for a bit and get the interaction with the technology to the point where users can easily and satisfyingly do what they want to. Get the basics to the right level, then continue with a balanced approach.

(Aside: Not all tech implementations are redeemable, I know. But I am setting those cases aside for now and assuming that much of it can be helped.)

To illustrate, think again about what happened in the iPhone. For all its glory, it introduced very little new technology. Its primary features existed in other released or demoed products. The "new" about the iPhone is the better way that Apple blended the technology and UX.

Alternatively, there is also evidence that drawing back the level of technology used while improving the user experience is also effective. Wired magazine shows the examples of the Flip video camera and Skype, among others, in a recent article. Now, I disagree with the assessment they make that these simpler and easier to use products are just "good enough" since the implication is that they are inferior to the more feature-rich products. By typical standards such as profitability and rate of adoption, the new breeds are superior to their overdone predecessors.

There are many other areas where one approach or the other is needed, and I'll point to voice interaction as my prime example. A great many applications out there use speech recognition technology that is only a few years old. But most of the applications were designed using old or no design principles by people with negligible design training, if any. Furthermore, the technology is often under or incorrectly used. And the consumer reaction has been predictable. Interactive Voice Response is one of the most maligned technologies in our current age. On top of that, it often fails to meet the business goals for which it was brought in. This was avoidable and can be made right. It requires simply taking a break from the bumbling techno-lust and focusing on getting the UX in line with the level of technology chosen. Or even reducing the use of technology while improving performance through a UX focus.

So, it's time for a reset. For catching up and scaling down. We could make a huge positive difference in both business success and customer satisfaction by improving the user experience to the level of being on par with the state of deployed technology. And then we could grow both together. Satisfyingly, profitably, successfully.

Care to join me?