| How is the VUI development cycle different? |
|
|
|
Developing for GUI, VUI — Huey, Dewey,
and Louie! What's the difference? Just as GUIs and VUIs differ in how they operate and are used (and you can learn more about that in "How are VUIs different?"), the process for designing them and putting them together differs, too. VUIs not only include all of the requirements, constraints, and protocols of building a graphical user interface, they add a few unique elements to the development cycle, as well. The RADICAL process: a model for developing voice interfaces (Adobe Acrobat PDF document; appears in a separate window) Although VUI development plans and procedures can differ radically (and in the document listed here, you'll see just why I chose that word) from GUI procedures, they do tend to standardize among themselves—there are "best practices" for developing VUIs—and you can find out all about my own recommended VUI-development procedures and protocols in this document. (Adobe Acrobat PDF document, opens in a separate window.) Sample callflow diagram for a VUI application This document is based on real work for a real airline that prefers to remain anonymous. (The specifics and some implementation and design details remain proprietary to the company and do not appear in this document.) This single document is intended to provide an overview, at a moderately high level, of the intended flow and interaction between the application and the caller. As a result, it also includes depictions of the data dips that will be largely transparent to the caller. In this way, both the client and the designer are able to get a comprehensive understanding of the appication's intended design, as well as a reference point and a means of quickly determining whether any critical data dips have been omitted or whether there have been any other oversights in the requirements analysis. The document includes:
Sample specification for a VUI application (Microsoft Word document; appears in a separate window) This document is based on real work for a real company that prefers to remain anonymous. (The specifics and some implementation and design details remain proprietary to the company and do not appear in this document.) This single document is intended to provide the agreed-upon basis and specification to being developing, testing, refining, and tuning the application prior to implementing a pilot program and finally taking it live and public. The document includes:
Copyright © 2009,Matt Prather |
