IVR Design Patterns


Published on

I gave this presentation at SpeechTEK 2009 in NYC to introduce an updated idea of design patterns to the IVR industry.

IVR Design Patterns

  1. 1. Design Patterns for Voice user interactions and interfaces Phillip Hunter [email_address]
  2. 2. What is a design pattern?
  3. 3. What is a Design Pattern? <ul><li>Patterns are Proven solutions to common problems Drawn from successful designs </li></ul><ul><li>Patterns make things easier to create and use </li></ul><ul><li>… And more attractive </li></ul>
  4. 4. Design Patterns - History <ul><li>Rich tradition </li></ul><ul><ul><li>Pattern languages emerged from Architecture </li></ul></ul><ul><ul><li>adopted by software architects in the 90‘s </li></ul></ul><ul><ul><li>Jennifer Tidwell brought mass attention to their use in ui over the past decade </li></ul></ul><ul><ul><li>others have built notable gui libraries </li></ul></ul>
  5. 5. Design Patterns have power <ul><li>For users </li></ul><ul><ul><li>enhanced recognition and comprehension </li></ul></ul><ul><ul><li>increased task success </li></ul></ul><ul><li>For creators </li></ul><ul><ul><li>Promote greater design & dev productivity </li></ul></ul><ul><ul><li>Promote greater creativity and scope </li></ul></ul>
  6. 6. Design Patterns can help <ul><li>simplify and speed the creation of common application pieces </li></ul><ul><li>break free from the system-centered constructs built into platforms and development tools </li></ul><ul><li>reassure non-designers </li></ul><ul><li>decrease the need for questioning every design aspect </li></ul>
  7. 7. Design Patterns are not <ul><li>reusable components or subroutines </li></ul><ul><li>a full how-to guide </li></ul><ul><li>magic spells </li></ul><ul><li>*fool* proof </li></ul><ul><li>Patterns are for use within holistic, context-based design thinking and processes </li></ul>Used with solid design thinking, patterns will help ensure that you create an attractive, usable application. Patterns will not do the full design work for you.
  8. 8. What does a Design Pattern contain? <ul><li>name and description of the pattern (solution) </li></ul><ul><li>examples of the applied pattern </li></ul><ul><li>the appropriate use of it (problem and context) </li></ul><ul><li>Rationale for the pattern </li></ul><ul><li>Potential problems / things to look out for </li></ul><ul><li>List of related or alternative patterns </li></ul>
  9. 9. Why does IVR need Design Patterns? <ul><li>“opportunities” </li></ul><ul><ul><li>design is still haphazard and usability poor </li></ul></ul><ul><ul><li>needless risks in the re-creation of that %@!(# wheel </li></ul></ul><ul><ul><li>ineffective guidance, such as wimpy top 10 lists </li></ul></ul><ul><ul><li>battle of egos: temperamental best practices </li></ul></ul>
  10. 10. Why does IVR need Design Patterns? <ul><li>We still shy away from real design principles </li></ul><ul><ul><li>We seem to like reinventing the wheel </li></ul></ul><ul><ul><li>we think history is a bad word (IVR patterns were begun then abandoned) </li></ul></ul><ul><ul><li>we dance to different music than the rest of the software world </li></ul></ul><ul><ul><li>we like to argue, not discuss </li></ul></ul>
  11. 11. We need IVR Design Patterns <ul><li>creation of library structure and content is underway </li></ul><ul><li>asking for submissions of your suggestions to [email_address] </li></ul><ul><li>will be available publicly sometime in 2010 online and possibly in print </li></ul>
  12. 12. What does an IVR Design Pattern look like? <ul><li>name and description, including: </li></ul><ul><ul><ul><li>Use of barge-in and other settings </li></ul></ul></ul><ul><ul><ul><li>suggested words and phrases </li></ul></ul></ul><ul><ul><ul><li>wording and constructs to avoid </li></ul></ul></ul><ul><li>examples of the applied pattern </li></ul><ul><li>the appropriate use of it (apps, users, etc.) </li></ul><ul><li>Rationale for the pattern </li></ul><ul><li>Potential problems / things to observe </li></ul><ul><li>Links to related or alternative patterns </li></ul>
  13. 13. What Design Patterns apply to IVR? <ul><li>Pattern Family Hierarchy </li></ul><ul><ul><ul><li>application characteristics </li></ul></ul></ul><ul><ul><ul><li>interaction sequences (AKA interaction design framework) </li></ul></ul></ul><ul><ul><ul><li>interaction events </li></ul></ul></ul>
  14. 14. Patterns for Application Characteristics <ul><li>application types </li></ul><ul><li>personalities </li></ul><ul><li>recovery handling </li></ul><ul><li>Global command handling </li></ul><ul><li>transfer policies and handling </li></ul>
  15. 15. Patterns for Interaction Sequences <ul><li>call reason capture </li></ul><ul><li>caller identification and validation </li></ul><ul><li>transitions from soliciting information to service </li></ul><ul><li>offering unrequested information </li></ul><ul><li>multi-part tasks </li></ul><ul><li>interrupt-able tasks </li></ul>
  16. 16. interaction events <ul><li>greetings and other initial prompting </li></ul><ul><li>language capture </li></ul><ul><li>special announcements </li></ul><ul><li>menus </li></ul><ul><li>open-ended prompts </li></ul><ul><li>yes/no questions </li></ul><ul><li>information requests </li></ul><ul><li>transition menus </li></ul><ul><li>confirmation </li></ul><ul><li>help </li></ul><ul><li>repeat </li></ul><ul><li>no match handling </li></ul><ul><li>no response handling </li></ul><ul><li>handling unsolicited input </li></ul>
  17. 17. IVR design pattern example <ul><li>speech reco repeat Menu - offers callers the chance to hear information again </li></ul><ul><ul><li>barge-in allowed, no T.O. or error prompting (no response = move on; oog might need to transfer) </li></ul></ul><ul><ul><li>wording should be casual and quick </li></ul></ul><ul><li>“ [You’re on flight 305 at 10:30 A.M. tomorrow.] would you like to hear that again?” </li></ul><ul><li>use for discrete information that callers need to remember after the call ends. use in place of offering repeat as an option within a following menu. </li></ul><ul><li>this sort of menu serves as a logical endpoint for the task selected by the caller. it also keeps a following menu less cluttered and focused on moving forward. </li></ul><ul><li>see also ‘embedded repeat command’ and ‘single item information playback’ </li></ul>
  18. 18. Thank You! <ul><li>questions? </li></ul><ul><li>submit </li></ul><ul><ul><li>[email_address] </li></ul></ul><ul><li>get in touch </li></ul><ul><ul><li>[email_address] </li></ul></ul><ul><ul><li>@designoutloud </li></ul></ul><ul><ul><ul><ul><li>469-853-9016 </li></ul></ul></ul></ul>
  19. 19. Sources & Resources <ul><li>http://www.welie.com/patterns/ - Martijn Van Welie </li></ul><ul><li>designing Interfaces - Jennifer Tidwell (designinginterfaces.com) </li></ul><ul><li>http://developer.yahoo.com/ypatterns/ - Yahoo! </li></ul><ul><li>http://www.visi.com/~snowfall/InteractionPatterns.html - Tom Erickson </li></ul><ul><li>http://www.uie.com/articles/componentspatternsframeworks/ - Jared Spool </li></ul>