(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.
I’ve always been fascinated by the cross-pollination that can be achieved when various fields and disciplines work together. As you might have noticed from my various posts, I also like to keep an eye out for opportunities in the UI field – things happening in other fields that may not be working together in ours yet, but whose potential definitively makes them worth a second thought and an evaluation to see what properties and ideas can be applied to UI design.
I recently ran across a series of 
How good is automation when it only works for part of the process? That’s what I often wondered while traveling since in many occasions I’ve found myself trying to use technology only to find out it didn’t save me from having to get in line at the airport. For example, sometimes you try to check-in online but get a message about having to stop by the counter to get your final seat assignment (aka someone overbooked the flight and will scramble at the gate to get you in). In other cases, you get an electronic version of the boarding pass yet have to go to a counter to check-in baggage.
Interesting article
It seems the current issue of BusinessWeek is focusing on 
After catching-up on all the topics and discussions from the 
I had a very interesting experience recently. I was at a customer’s site performing some on-site multi-modal usability testing that involved participants who could perform some of their day-to-day operations via a palm-based device using the keyboard, the device keys, the stylus, or of course, good old speech recognition.
That’s right. How many times have you been outside and saw one of those humongous ad displays telling you about the next great thing since sliced bread? Well, what if you could now interact with those displays, and not only that, but even be able to play with other bystanders!
How many times have you been frustrated with a telephone or customer service experience? Some people opt for making their feelings public, and hence we often find videos and recordings of those experiences out in the media. Some others (myself included) like to keep them as “war-stories” that can then be shared during parties or presented at conferences.
Entries (RSS)