Archive for the 'Usability' Category

As you know, I enjoy looking at other fields that might have design elements that could be leveraged in a speech and multimodal world.

My latest discovery was the film “Objectified” by Gary Hustwit. Even though the documentary is centered around the topic of Industrial Design and the process by which well known products are designed, created and injected into the marketplace, there are some great quotes by various designers that I couldn’t help but feel compelled to share with you and analyze in an attempt to find a way to apply them to our field. With so many quotes, I though this might be better off divided in parts so people can add comments and share their own insights and experiences. Let’s get started:

“What we really need to do to design is look at the extremes – the weakest, with arthritis, the athlete, the strongest, the fastest – because if we understand what the extremes are, the middle will take care of itself.” — Dan Formosa, Design and Research, Smart Design

Wow, what a way to start this topic! After readings this one, I couldn’t help but feel a little guilty about perpetuating the common design approach of the 80-20 rule. We try to capture what 20% of the population which will use 80% of the features might do, add support for a few other common “corner cases”, and ignore the really obscure and unlikely scenarios altogether. This point definitively made me wonder what if… what if we were to do it backwards, design by looking at those extremes - the distracted caller, the multitasking mom, the user that requires extra time to process the information or respond - and letting the middle take care of itself.



Case in point, the creation of the Oxo kitchenware, a peeler originally designed for people with arthritis that turned out to be more comfortable and easier to use for everyone!


“What we’re really always looking for whenever we design are ways we can improve the way people do things or improve their daily life… without them really even knowing, ever thinking about it.” — Davin Stowell, CEO & Founder, Smart Design

Another quote from Smart Design, but this time addressing the reasons behind our designs. How often are we really looking for ways in which we can improve how people do things or improve their lives? How often can we articulate this need and help evaluate it in the context of other seemingly more important needs such as completion rates, retention and automation? Can we really tell we designed something that not only solved someone’s issue or allowed them to complete their task but that in fact had a positive impact on them without them even knowing? Quite a challenge (and intrinsic motivator for me)!

“Good design should be innovative. Good design should make a product useful. Good design is aesthetic design. Good design will make a product understandable. Good design is honest. Good design is unobtrusive. Good design is long-lived. Good design is consistent in every detail. Good design is environmentally friendly. Good design is as little design as possible.” — Dieter Rams, Former Design Director, Braun

I think Mr. Rams said it perfectly. Seeing what goes on inside the minds of product creators behind brands like Braun and their philosophy definitively makes me appreciate the responsibility of a designer.

That’s it for part 1. Stay tuned for more quotes and nuggets of wisdom. And if you get a chance, watch the movie, you won’t regret it (and your users will appreciate it)!

During any Requirement’s Gathering process, one of the hardest yet most critical steps involves finding out the features that will be offered to the users. Figuring out the final set normally involves talking to agents, listening to the different business units, looking at statistics, etc.

Furthermore, if the customer is migrating from an existing system to a new one, part of the process also involves reevaluating the set of features currently being offered to determine which ones should be migrated and which ones should be eliminated for good (which very often becomes a challenge by itself since customers tend to feel that by doing so, they are “loosing” functionality)

Some of the tools available to us include performing a Usability test on an existing system, doing a benchmark analysis to compare features offered by competitors, looking at usage data to determine the frequency of usage of each existing feature, or setting up focus groups or customer surveys to explore the likely usage of new features.

So yes, there are way to figure out how often they might use a certain feature or what they might think about it, but how do you gauge how deeply your users care about those features?

Well, while watching a recent Burger King stunt (an interesting mix of market research and marketing) in which they made one of their US branches a “Whooper Free Zone”, and recorded via hidden cameras the reactions of their customers upon being told that they were no longer serving Whooper sandwiches (see video below).

This stunt made me think about a tool that designers don’t use very often: Subtraction.

By that I mean that very often we run complex studies and champion-challenger scenarios (aka A-B designs) to figure out what the best combination of items might be, or what the impact of adding one more choice will have on a user base. But how often do you test the impact of removing a choice both from a performance as well as from an emotional perspective? (and no, I’m not talking about those bad designs where options are so buried down or words are so poorly chosen that it’s almost impossible for users to find what they need or realize what they need is in front of their eyes (or ears).

So, next time you’re thinking about your users and the options they need, consider subtraction as one more tool in your ever-growing UI toolkit. And if you’ve used before, I’d be very interested in knowing what your results were.

Oh yeah, it’s that time of the year again. If you’re planning to attend this year’s SpeechTEK in New York, please stop by and say hi.

Also, you can now look at the final version of the program. In particular, I would like to invite you to the following sessions:

  1. Introduction to Voice User Interface Design (STKU-2)

    Sunday August 23rd, from 1:30 PM to 5:00 PM. This workshop is designed to quickly get those new to VUI design up-to-speed so they can make the most of the Principles of VUI Design track at the conference

  2. Efficient Design (B102)

    Monday August 24rd, from 11:15 AM to 12:00 PM. Here we’ll talk about “Truths and Myths About Reusable Designs”. How can you design for reuse? Can user requirements be captured the standard way?

  3. Bilingual Spanish/English Design (B301)

    Wednesday August 26th, from 10:45 AM to 11:30 AM. Here we’ll talk about “How to Present Names of
    Geographical Locations in Spanish Systems”. Yes, listening for and capturing names of places seems like a trivial task, but what factors should be considered when making translation/pronunciation decision? What do those decisions say about you and your company?

Safe travels, and see you there.

A very interesting report from Nielsen was recently published highlighting some of the challenges mobile users face when accessing web information.

Aside from the sad news about average success rates being around 59%, it was interesting to me to see how most of the Mobile Problems outlined in the report can be actually seen as opportunities to seriously consider the use of Speech Recognition.

I know most companies suggest Speech Recognition as the killer app for mobile devices, but I would argue that it should be seen instead as the ideal complementary mode of interaction when navigating the internet and retrieving information on mobile devices, not as the silver bullet that would solve all mobility hurdles.

For example, thinking about speech in the context of those problems raised in the report:

  • Small screens: Yes, small size is a natural result of being portable. Yet, having a limited number of options at any given time and relying on short-term memory are the bread and butter of most Speech Recognition Systems. Therefore, adding an audible element and allowing users to express themselves in more natural ways helps compensate those visual limitations. Furthermore, multislot interactions and natural language understanding help alleviate the challenge of multiple windows and advanced behaviors present in purely visual interactions.
  • Awkward input (especially for typing): Once again, Speech Recognition shines here since it’s the facto way of interaction amongst humans. Words can easily trump visual counterparts such as menus, buttons, and links not only because of how natural interactions are but also because it avoids the inherent limitations of tiny keypads, trackballs and mini-keyboards.
  • Download delays: Even though Speech cannot solve the problem of being able to download screens faster, it can help in those instances where information can be delivered in an audible form since users can continue to interact with the system and move along their intended goal since prompts and logic can be embedded in a device without requiring network connectivity or optimized and compressed for faster delivery.

An interesting discussion came up this week where there was a debate about the length of menu choices and how short/long options should be to help users move along in both an efficient and successful way through a system.

Interestingly enough, around the same time I ran across an article from Nielsen talking about taking about links and how well can users predict what will be contained within each link.  I’ve mentioned in the past that I feel there are many similarities between the web world and the voice world, so thinking along the same lines, I feel web links are the siblings of menu choices in speech, so I felt the part where he talked about the results of only showing the first 11 characters of a link was relevant for that discussion:

The two winning links (“Gift Cards” and “New Custome”) also showcase principles for effective Web content.  Both links:

  • Use plain language
  • Use specific terminology
  • Follow conventions for naming common features
  • Front-load user- and action-oriented terms

The point being that the importance is not really on the length of the word but on its meaning.  For example he found the worse links were the ones that only showed “Introducing” and “Working whi” that had the same length as the winning ones but were bad because of:

  • Bland, generic words
  • Made-up words or terms
  • Starting with blah-blah and deferring the information-carrying text to the end

What this means in practice is that using single word commands on a menu (e.g. “Emergency”, “Billing”, “Status”) does not necessarily make menu choices easier to understand, more intuitive for users, or faster to navigate.  On the contrary, they may limit the user’s ability to infer what can be found underneath them, creating the exact opposite effect.

JTLYK   :)

Smashing Magazine just published an article about Useful Techniques for Good UI Design, that even though concentrated on Web Applications, I felt there were a few techniques that could be reviewed with an eye towards VUI design:

  1. Highlight important changes
  2. And by this I don’t mean “Please listen careful for our menu options have changed”. Here we’re talking about system status visibility - knowing where you are and that actions led to expected results. Implicit confirmations are a good example of this.

  3. Enable shortcuts in your application
  4. The key concept here is to offer users more responsive user interfaces. In the case of the phone, this can be somewhat compared to having “touch-tone equivalents” which allow expert users to breeze through applications without having to wait to be prompted for input. But here I would also argue that other things would fall under this same principle: good command selection, “shadow” options that even though not prompted for can be supported if tuning data backs up the decision, and even “parallel” choices which allow someone picking one branch to swiftly change “branches” without having to “go back” or return to a “main menu”.

  5. “Upgrade” options
  6. I feel this would be similar to having functionality available for “expert users”. Proper use of barge-in as well as multi-slot support allows someone to interact in more “advanced” ways with a system keeping such a transition simple and intuitive.

  7. Advertise features of the application
  8. And no, sending out “user manuals” for applications does not qualify for this. Here we would be talking about pointing out “new” features or even “advanced” features that are available. As with most non-task-oriented information, this should be presented only after the user has successfully completed their task.

  9. Use “color-coded” lists
  10. Items appearing together are an issue, no matter what type of interface we’re talking about. Therefore it is really important to put attention to the different tools at our disposal to avoid this issue: voice intonation/emphasis (such as making menu options clearer), word choice (avoid confusion amongst different choices), silences (natural pauses to allow mental processing of the information), etc.

  11. Offer personalization options
  12. I’m sorry to say this has been out there for quite a few years for most interfaces, yet voice user interfaces hardly ever offer them. It may be harder to do than with visual interfaces (where you can change colors, rearrange items, etc.) yet small things like offering only relevant choices based on someone profile or remembering the last tasks they’ve performed go a long way in making users feel like they “own” the system.

  13. Display help messages
  14. Help is definitively one of those topics that has been debated a lot, and like most controversial ones, whether or not it should be used and how it should be used can be summarized in two words: “it depends”. Personally I feel help should not be a stand-alone piece of a design (whether it is a tutorial or a separate collection of help prompts) but rather an integral part of design – commands offered should be helpful to a user, error messages should add relevant information to help users recover, transition messages should help users know where they are and where they are going, etc.

  15. Design feedback messages carefully
  16. Here we can think about transition messages (exit prompts) and error recovery prompts. Here, there are various things that can be done to make them more effective: control voice intonation so as to convey the right meaning, reword questions and statements so as to convey the same meaning without simply “reprompting” users (if the problem had to do with users not understanding you in the first place, simply repeating is not going to help at all)

  17. Use tabbed navigation
  18. This is one of those areas where visual design has an advantage over non-visual design. Nevertheless, good information architecture can help obtain similar results, where applications reflect user’s mental models making it easier for them to know what choices mean and how the system works. This makes users feel at ease since they feel more in control.

  19. Darken background
  20. Conversely, here non-visual design has the advantage since all interactions happen in sequence. No need to “gray out” parts of our design since by the time we move on with a new “task”, all previous information now belongs to the past.

  21. Lightboxes and Slideshows
  22. The concept here is to allow users to navigate back and forth. In the visual world there are a lot of tricks to reduce the noise and allow a user to focus on a particular item. In the case of non-visual design, there are ways to do similar things when the system has been properly architected, which should include consideration of “go back” behavior that would contextually match a user’s mental model, as well as proper “sub task” definitions so that if users need to make a change or update a certain piece of information, they don’t have to start all over again or get confused about how to do it.

  23. Short sign-up forms
  24. This is another one where non-visual design has the opportunity to leverage information. The whole notion here is to minimize the effort needed to identify a user and to speed up the process. On one hand, this means taking advantage of what technology has to offer: ANI identification, DNIS separation (ideal for language selection), CTI (please, please, please don’t loose everything that the user has accomplished so far). And on the other, there are design techniques such as the removal of “optional” elements if that allows a user to proceed (and especially if that avoids confusion and distraction from the user’s real goal).

We’ve heard about the global phenomenon of a population that is aging, yet there are very little talks about what design strategies should be used for them.  Other than the classical stereotypes - louder volume, slower pace yet not condescending, pitch within a certain range, more information, etc. – the impact this tech-savvy population will have on how interfaces are being designed is still vague and uncertain.

Quick fact: currently, the population under the age of 5 years old exceeds those above the age of 65. It is estimated that within the next 8 years, that trend will reverse. By 2050? They will double the number of people under the age of 5.

Source: U.N. Department of Economic and Social Affairs, Population Division

So, if we were to consider all the things that will change around us to accommodate those users – from healthcare products and services to how stores are arranged and houses are build – it should be easy to realize the wide range of possibilities and opportunities to improve interactions – from how information is provided to what types and levels and services are expected both from automated self-service solutions as well as live human beings.

Maybe getting serious about the topic and continuing research will finally take over the assumptions and stereotypes that so often appear in most user designs…

While doing some research on Multimodal Usability and User Interfaces, I ran across a list of Three Main Attributes of Multimodal User Interfaces, which on careful thought, can definitively be applied to ANY User Interface. It was a nice refresher which reminded me of why good design is so difficult to achieve, but very rewarding.

Good User Interfaces can be judged based on their:

  1. Effectiveness: Whether a user can achieve a desired goal or a certain task with a predefined degree of perceived accuracy. This one has to do directly with our users and their environment. Good questions to ask ourselves: What level of accuracy are you designing for? What completion rates can you expect from certain design strategies? How satisfied will your users be after completing a task?

  2. Efficiency: How much effort (fatigue, frustration, cognitive demand, stress, discomfort, number of tries) and resources (time) will those users need to complete a task. Good questions to ask ourselves: How long is it going to take for an average user to achieve a certain goal? How many error corrections can we expect from certain design strategies? Will users obtain something of a higher value than the one they are putting into the interaction?

  3. Learnability:Whether a user can easily discover the functionality contained in a system and quickly learn how to use it. Good questions to ask ourselves: How intuitive is my design? Based on the context on the interaction, does the funtionality offered by the system match the user’s expectations? How easy is it for users to explore and discover new functionality and advanced features?

Based on these attributes, where do your design stand? Come on, don’t be shy…

It seems one of the most frequent questions that come up when designing a new user interface is “how many options should appear on any given menu?” which depending on the answer is almost always followed by “how many levels down should the system have?”

And believe me, neither one has an easy or absolute response. As witnessed by some of the heated debates on the VUIDs list, the old standing guideline of “five options or less” was recently put to the test when Patrick Commarford and James Lewis from IBM published the article entitled “A Comparison of Broad Verses Deep Auditory Menu Structure” where the results seem to indicate that when comparing broad vs. deep menu designs, giving callers a single menu with many options (providing touchtone fallback) yields better results than using fewer options supported by submenus.

Aside from all the points, concerns, comments and objections raised by both the authors, the VUI community and other blogs, in my opinion I think it’s going to be really hard to reach a consensus if the main focus of the discussion if to agree on whether *5* is the right number of choices or not. The problem I see with trying to find that ‘ideal’ number is that a number by itself doesn’t mean anything. In this case, I think the devil is in the *context*.

In other words, any attempt to generalize what a good design should look like without taking into consideration the context of the application is not very responsible. We all know there are many factors that need to be taken into account when designing any system: caller’s age, demographics, type of application, caller’s objectives, business goals, etc.

Furthermore, when evaluating possible menu choices, the frequency with which each choice is needed and used by callers should not only drive their position within the menu but also the decision of whether or not the option should be in that menu in the first place (for example, if the top 3 choices on a menu are used 45%, 31% and 20% of the time respectively, then adding one more choices that’s only used 1% of the time should not be considered – in fact those calls are likely to be better handled by agents in the first place).
When all those factors are added to the mix, then an appropriate design *strategy* can be conceived.

For example, when thinking about the context of an application, imagine a system asking callers to choose a bird species – “And which type of bird is circling around you: dendrocygna, gelochelidon, herpethotheres, or tachycineta?”. In that scenario, unless you’re a birdwatcher, you’re likely to be overwhelmed even after hearing only 3 choices. The counterpart of course would be to ask for something so common and known that the number of choices in itself wouldn’t make a difference – “And which planet are you calling from: Mercury, Venus, Earth, Mars, Jupiter, Saturn, Uranus, Neptune or Pluto?”

I definitively believe the industry should strive to find more answers to long standing questions, particularly when those responses can be backed up by real world data, but in this case, I think that unfortunately the answer to the question whether to go broad or deep on menus still is… it depends.

(I found this great article by Jared M. Spool) and decided to do an adaptation)

From observation and analysis, it seems teams who focus on the long term objectives of a project and an organization are far more likely to create designs that really pay off for the organization, whereas short-term vision teams end up not only not meeting the caller’s expectations, but often having to revisit the design and redo most of the work later on.

It is important to understand that the right approach to any Redesign involves turning the system into a living, breathing entity that evolves over time and grows with the caller’s and organization’s needs.

Here are seven essential long-term components to reach a successful phone system redesign project:

1. Make Sure You Have A Vision

This can be as simple as to look five or ten years into the future and ask the question, “What will calling our system be like on that date? What experience will the user have?” Team members from the best organizations have a consistent, clear idea what the user’s experience will be like in the future. Such a vision helps drive the design as well as any future changes/enhancements (“will this change get us closer to that vision?”).

It’s critical the vision not focus on future technology but instead on future experience. What are the steps in today’s process that makes things cumbersome or frustrating? How could the experience become more delightful?

2. Spend Time With Your Users

To successfully redesign (and to design for that matter), you need to be in close contact with the source – your users. You need to know who is using your system and what they are doing with it. You need to know what works and doesn’t work for them.

Based on the number of new implementations and changes happening out there, it seems many companies finally understand the importance of the telephone channel as a critical touch point with their customers. Unfortunately, even though some of those systems are getting major face lifts (heard any new “please listen carefully as our options have recently changed” recently?), most of the time decisions are made without even looking or listening to their users.

When preparing for a redesign of any system, teams should not only focus on what the new design should do but should also spend the same amount of time listening to real caller interactions with the existing design as well as sitting down with call center agents.

3. Reduce Risk By Working In Little Bits

Going back to thinking about design as a never-ending, always-improving process, the most successful teams keep their projects small. They don’t attempt to redesign everything in a single launch; instead, they work on one small section at a time.

Otherwise, you end up with complexity at all angles: the scope of functionality is larger, the number of stakeholders is larger (each with their own concerns), the number of archetypes the team is designing for is larger, more compromises are made, and the risk is much higher. If things don’t go as planned (as it often happens), it’s a huge problem for everyone, often with more visibility in the organization than the team would like.

Teams that only focus on a small portion of the application at a time reduce all those factors and risks while being able to concentrate on those critical areas that will make or break the design. Plus of course, reducing scope and concentrating on the most used features yield much better ROI numbers and timeframes.

4. Have the Right Skills Internally

Here recommendations might slightly different from what a regular web project might require. Even though on the web the best teams are less likely to hire outsiders to do their designs, building the right speech and VUI skills in-house is not only hard and too specialized, but may get in the way of a successful redesign. Nevertheless, since the idea is to have a design that evolved over time, it is up to the company to maintain, change, update and enhance the application as user’s needs change.

Therefore here the suggestion would be to have a dedicated in-house team that would work side-by-side with someone with experience in these types of systems so they can learn not only the intricacies of the design but also the reasoning and the strategy behind it (which will also help them become advocates of it and defenders of the user experience). That way, external resources can be later on used as mentors or as a way to make larger changes faster.

5. Think ‘Standards’

The VoiceXML and SRGS standards are the successful teams’ best friends. Careful application of the standards can dramatically shorten the time it takes to make changes down the road, as well as to simplify the integration of third party components and technologies.

Even if an original application didn’t start out as standard-compliant system, it’s worth the effort of slowly converting it. As functions/modules/flows are redesigned (in little bits, remember), changing them over to be standards-compliant is an effective approach. Every new redesigned area helps improve the team’s skills in using standards, thereby making the next section even easier to convert over.

6. Have a Plan for Change

Aside from having clear implementation and maintenance plans in place (system architecture, internal processes, etc.), it is critical to also plan for how the users will experience the change. Will they just call in one day to find an entire new experience or will the change slowly happen over time, almost imperceptibly? Will they be notified in advance of what the new system is prepared to do for them? Are all other contact points (web, branches, etc.) ready to support the cross-channel interactions that will be generated by the new system? Will the agents be prepared to handle the temporary increase in the number of questions and issues that often arise as soon as a new system is implemented? (and no, asking callers to “please listen carefully as our options have recently changed” doesn’t count as a plan)

For example, one interesting approach some companies take on the web is to slowly convert users over to a new version of a system by offering the new options while still allowing users to continue to use the old functionality/version for a while (this may be particularly critical for caller populations with a wide gap between infrequent callers and expert users, specially if moving from a DTMF system to speech). That way companies can assess the risk of changing the functionality out from under these users versus the cost of supporting both interfaces.

7. Understand the Internal Processes

Unfortunately, just as it happens on the web, many teams approach the redesign process much like they’d approach the design of a brochure or a monthly statement. Designing either one has the advantage that, at some point, it is printed and delivered. Once that happens, it can’t be changed — it’s done. The only thing is to start over with a new one.

The problem of course is that if you think you can think about a new design, implement it, then pay attention to other business, not giving the system any further attention, you’ll be in trouble.

The most successful teams consider, in the planning stages of the project, what the long-term internal processes will be for updating/enhancing the system after the design changes (due to new user’s needs or business requirements). How will they add new functionality? When do they remove low usage flows? Who will edit prompts before they go live? Who will review changes? Who will decide about changes to the user’s experience?

Understanding how the organization will handle the ongoing system changes shortens the time it takes to make improvements, reducing the need for a risky major relaunches (or sometimes even worse – pulling out the new system and bringing back the old one).

Conclusion

Careful consideration of long-term factors dramatically increases the odds a team will produce ongoing results that have considerable business impact. Teams ignoring these long-term components may get a new design launched, but will likely find themselves reliving the difficult experience again in just a few months.