We create Visual User Interface (VUI) designs that produce functional and efficient interfaces that meet the customer’s needs.
What happens we get a request from a prospect or a partner looking to engage with a prospect? We need either the existing call flow that represents the desired state of the existing IVR or documentation. If the customer can provide us neither document, we have the capability to call into their IVR. Also we perform an IVR mapping. You should to get the documentation as IVR mapping can miss things, especially if there is account specific behavior.
We take the call flow and put it into Enterprise Architect. Once the flow is in and the objects have been created, we perform Function Point Analysis. Basically, which estimates a project’s level of effort based upon Inputs, Outputs, Decision Points and External Interfaces. This estimation provides the total level of complexity in Function Points. We then apply the hours per function point modifier to determine the total level of effort.
Following the kickoff meeting, the designer or design team begins gathering requirements. This involves several types of activities including, but not constrained to, customer meetings, data gathering, persona definition and brainstorming. All of this effort is geared towards producing a General Solution Document (GSD). The GSD is simply a restating of the requirements from the statement of work. The main goal is to clarify the requirements and define levels of effort to be done in our terms. The GSD becomes the vehicle we use to clarify our understanding of the business process flow. Furthermore, this includes associated requirements through Call Flows and Robustness Analysis.
During this phase, at the customer’s direction, we perform a competitive analysis. This effort consists of us calling into competitor IVRs, recording the transactions, mapping out the IVR including the options. Also this includes evaluating criteria in the IVR including design features, best practices, persona and design fundamentals. The output of this effort is a score card of IVRs. This score card can be used to provide input into the customer’s design direction. Similarly, this is with the goal of meeting or exceeding what the competition is doing.
Usability testing provides unique insights into how an application will be used, before the application has been fully developed. This is done using rapid prototyping and Wizard of Oz testing or “WOz Testing” methods. Additionally, other usability centric activities like call monitoring and surveying can be employed to give an indication of how a pre-existing application is performing. These activities can be performed either before requirements or after, depending on compliance factors. Any time and resources spent on usability results in far fewer defects and a superior user experience.
High Level Design Phase
During this phase the goal is to produce two things: a Global Design Strategy and Sample Dialogs. The Global Design Strategy is a document that contains the forms and conventions for VUI design as it applies to the machine. It is expected that the designer will use other designers via brainstorming meetings and reviews to create this. The Sample Dialogs are call scripts that show example scenarios of how a caller will likely interact with the project. They exist to provide examples of what the VUI design is going to sound like and will not be carried through to the specific customer. The graphical representation of the application, however, will be maintained and eventually included in the detailed design specification. The Global Design Strategy document and Sample Dialogs together serve to make sure the designer is on the right track before starting the detailed dialog design.
Detailed Design Phase
The Detailed Design Specification (DDS) contains all the information necessary to implement the voice user interface portion of the application. The document contains the high level graphical view of the application, as well as a detailed description of each “state” in the user interface. The intent is to have a full design document containing the dialog specific prompts but to leave out repetitive prompts, such as retry, timeout and help prompts, that are generated based on the globally set initial prompts. Any special prompts or dialog specific behaviors should be included. This phase will include completing all of the details, including retry, timeout and help prompts, specific to the local dialog. This phase is also where the grammar definitions are completed. The use of brainstorming meetings and internal heuristic reviews, as well as formal reviews internally and with the customer, will be used to produce the document.
Although it isn’t part of the documentation produced in this phase, it is typically good practice to make sure that the voice talent is chosen during this phase. Because the prompts and persona are tied to that selection, it’s important to have it done here to avoid unnecessary changes later in the process.
Although the bulk of the effort going on in this phase is being done by developers and testers, there are still plenty of tasks for the designer. In order to finish the application, recordings are needed, and it is the designer’s responsibility to coach the voice talent. After the application is completed, it is the designer’s job to perform a walkthrough of the user interface, making sure that the finished product matches the intent from a VUI design standpoint.