The VUI design process, like any design process, is iterative and should span the lifecycle of a product. There exists many different ways to characterize the VUI design process and, depending on the source, there exists any number of phases. Regardless of how these sources segment these activities, there is common agreement that the fundamental activities include Discovery, Design, Deployment and Evaluation. We discuss these activities below with the assumption of a waterfall methodology. While agile work methodologies segment the work a bit differently, the basic necessary activities do not change.

Phase I: Discovery and High Level Design & Validation
The purpose of the Discovery or Definition Phase is to: (1) understand the business requirements, and (2) translate the business requirements into a schematical representation of the application solution. During this phase, designers may use a number of strategies to ensure the application will provide the required functionality and to ensure that the various tasks may be performed relatively easy. User engineering tools such as ethnographic analysis, contextual inquiry, Wizard of Oz testing (WoZ), and structured walkthroughs are useful to ensure that caller expectations of the structure and function of the application are met along with the needs of the business. The tangible artifact in this phase should be, at the very minimum, a high level schematic of the application. Sample calls go hand in hand with the high level call flow, as they aid in visualizing how the system will flow. These represent critical paths through the application, rather than every path. They are not meant to be comprehensive. A skeleton version of the user interface design specification (UI spec) may also be created during this phase. This will have all states as shown in the call flow diagrams, and will have connectors (usually linked bookmarks), representing the line connectors in the call flow diagrams. At this stage the inital prompts for interaction (dialogue) and play states may be included, but not retries or help prompts. This prevents rework later if initial prompts change during reviews (as they invariably do). Also helpful for client stakeholders are a series of accompanying use cases. Crafting an application persona and style guide is pertinent to this phase, if desired. These will document the sound and feel of the application, and should be a projection of the client's brand. Caller archetypes are also created during this phase. These are fictional depictions of real callers who might call the system. They are not meant to be exhaustive, but representative of the type of people who might call.

Phase II: Detailed Design and Validation
Having received concurrence on the high level design of the application, the voice user interface designer will go about drafting a detailed call flow of the application. During this phase, the application logic, prompts, and grammars are crafted. The tangible artifact from this phase may be either a graphical call flow or a written document, which ever is easier for all audiences (e.g., developers, testers, stakeholders) to comprehend. The user interface design specification (UI spec) is the most common document, filling in error handling, retries and help prompts, and database interaction information such as inputs and outputs, if needed.

Phase III: Deployment, Testing, and Tuning
No matter how thorough you believe you were in drafting VUI requirements, inevitably, development will require some clarifications. It is important to share with them what your intentions were lest they will “fill in the blanks” themselves, and not always in keeping with agreed to designs. Additionally, it is critical that VUI designers collaborate with the testing function. Good testers will not only test against VUI requirements but they will also serve as a fresh pair of eyes on which to gaze upon your designs. Listen to them when they make comments – often, they can provide valuable feedback that might otherwise go overlooked by designers who are too close to the effort. At this stage, usability would be performed. One or more usability test report(s), documenting the findings of the usability testing and outlining the recommended changes would be produced. See Usability Testing for more information. Finally, the value of application tuning cannot be overstated. Tuning involves not only grammar tuning (to maximize opportunities for recognition accuracy) but also application tuning. After an application has been deployed for a time, say 30-60 days), it is important to look at a subset of data for a given date range to assess how well callers are traversing the various application logic legs. It is with this analysis that opportunities for enhancement can be realized. One or more tuning reports, documenting the findings of the tuning effort, and outlining the recommended changes would be delivered.