Whose IVR Design Is It Anyway?

Everybody Gets a Seat

Your company just landed a big IVR project and employees are ecstatic. Sure, it's a huge win, but project personnel might feel as if they would rather eat glass than design it. It's not the scope of the project that's troublesome, but rather the people who will be involved. The designer has an ego bigger than a conference room. The grumpy developer says "no" to everything. The quality assurance and control people think team members must be out of their minds, and the usability expert goes home every night and cries. The end result can spell a parting of the ways between client and vendor, and worse, a ruined business reputation for the vendor. But a nightmare situation can be averted if you take the first step—together.

Industry veterans say that collaboration between team members and business stakeholders is crucial. Dave Pelland, director of UX innovation and design at Genesys, says that many companies have IVR design meetings between just a business stakeholder and a designer who is supposed to capture the requirements of the client. In his department, Pelland puts the lead designer and lead developer in front of the customer.

"This immediately helps, because now the designer is paying attention to the user interface, and the developer is paying attention to the back end," Pelland says. "There needs to be constant communication, not walls."

Nuance brings all the stakeholders to the table for collaborative input. "Getting the whole team together from the customer side and the vendor side in the same room should be a priority," Hebner says. "The decision makers from IT, the business, the call center—we're making decisions all in the same room."

It's all about documentation at Convergys. Goss says that the company has a specific process when it comes to formats and templates. From a communications perspective, no matter what the project is, the design, development, and test groups need to have the same expectations about what the documentation contains.

"It doesn't matter who the customer is. We have a UI requirement specification that we follow, an internal tool that we use to build a high-level design," she says. "That same tool will be used to build the detailed design and generate some of the code for developers and also some test cases."

At DMG, one of the first things Fluss and her team do is speak with C-level executives so that they understand the company's goals. To get the full picture, she also talks to others in the organization: call center workers, QA staff, trainers, and business analysts.

Fluss says she employs a checks and balances process. "Every step of the way, we write up [suggestions] and get approval," she says. "Because of all the research we do, you can't debate what needs to be done. We get to the point where we tell them exactly what to change—the pacing, the wording. We're actually able to project what kind of benefits an organization can gain by making these changes."