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