How Will We Justify VoIP?
The convergence of voice and data networks is inevitable, yet the industry can't explain why.
July 1, 2002
![Network Computing logo Network Computing logo](https://eu-images.contentstack.com/v3/assets/bltde8121fc52c5c8f3/blt3f3d0318f746b1c2/65a530e4187606040a1d8b8c/placeholder.png?width=1280&auto=webp&quality=95&format=jpg&disable=upscale)
So what will make users want VoIP? The answer is right under your nose every time you make a call: Users want good interface design. The phone does much more than connect users -- it can access voice-response systems, for instance. But automated menu systems have become much too complicated, forcing users into such a long, meandering path of voice prompts that by the time we've heard them all, we've forgotten why we called in the first place. As these systems grow, serialized prompts collapse under their own weight. If the phone could display menus, these systems would be substantially easier to use.
We are too accepting of bad interface design in telephone-based applications. Case in point: To charge a call to my company calling card, I have to press 0 and then the area code and number. But if I forget to press 0, an automated attendant scolds, "You must press 0 before the number." Now, if the system is smart enough to realize I didn't press 0, shouldn't it be smart enough to do it for me? Of course, calling-card providers are hardly at the forefront of human-factors innovation. Their improved version is likely to say, "If you'd like us to press 0 for you, please press 1."
And serialized voice prompts are just part of the problem. The telephone interface is brain-dead. Any high school computer science student could improve on the 12-key keypad -- and he or she probably would remember to put the Q key in there too. Furthermore, each phone system has a different use for the star and pound keys -- there are no standards for their usage. We can't even agree on what we should call these keys -- in the Australian vernacular, the pound key is the hash key. A hash button sounds like the speed-dial key for take-out services in Amsterdam, if you catch my drift.
Most of us have used a telephone since before we were born, yet companies still spend good money to send employees to "telephone system training." They supply cryptic cheat sheets and 40-page "quick" reference guides, and insist that users memorize random button sequences to perform the simplest functions. They also force people to perform unnatural acts, like hanging up on the caller before they can transfer a call. Why? Bad interface design.
Of the myriad features on current phone systems, only a handful ever get used, because the interface is so poor. A lot of useful stuff is buried in there somewhere, but advanced features are just too complicated for users to embrace. Programmable softkeys aren't the answer. You can label a button Park but that won't help users understand the function of moving a call into a holding area for access from another phone -- though the Park button might make people ask if they can put a call in Reverse too.PCs make for very flexible interfaces, but running telephony software on a PC just doesn't cut it. "PC" is to "reliable telephone" as "Eastern Europe" is to "finely crafted automobile." We need phone-application vendors to present their products in a more appealing way. And we need a reliable telephony endpoint that is a platform with an extensible user interface, designed for both data and voice access.
You May Also Like
Maximizing cloud potential: Building and operating an effective Cloud Center of Excellence (CCoE)
September 10, 2024Radical Automation of ITSM
September 19, 2024Maximizing Manufacturing Efficiency with Real-Time Production Monitoring
September 25, 2024