The DialogDesigner tool is sufficiently a-theoretic to not require any specific development method or workflow. The model concept, however, is most well-suited for task-oriented dialogues within relatively well-structured domains. Below, we describe some options that we have tried out.


The first step is to quickly define a number of groups and states, and provide main transitions between them. This work primarily takes place inside the designer, defining states, grouping them together, and arranging them linearly in order to match the task structure by moving them up or down. Occasional excursions are made to the prompt editor for defining the prompts and to the graph tool for viewing a graphical presentation of the emerging dialogue model.


When main transitions have been defined, one may also begin to use the simulation tool. Here one may walk through the dialogue model by selecting transitions and reading aloud the activated prompts. It has a good effect to let one person (the designer, e.g.) control the simulation tool, whereas another person (could be another designer, a customer, or a genuine test person) plays the role of a user.


In the graph tool groups, states and transitions may be presented more or less detailed, as selected. The visual presentation and the ability to focus on specific substructures makes the graph tool a nice supplement in the analysis and presentation of the dialogue model. It is not (yet) possible to edit the model in this view.


Precise, model-based tests may be defined by generating scripts in the Woz simulation tool. In the final test phase, the log edit tool can be used to document and provide an overview of notes. Systematic tests can be performed by following the scripts step-by-step. In this way, the implemented system can be tested in a reproducible and model based way.


In the prompt editor window, phrases can be defined, grouped into kinds such as cities and numbers, and stringed together into prompts, which again may be put together into larger prompts. Phrase lists and prompts lists may be generated for convenient use in speaking and recording the phrases.


One of the difficult, but needed activites in the development of dialogue systems, is to communicate to customers and domain experts what the dialogue model implies and to get their reactions to the model, so that as many misunderstandings can be removed as possible, and a mutual agreement can be achieved. DialogDesigner achieves this in several ways: Simulation walk throughs are efficient in letting the customer experience how the dialogue works, graphs and html reports provide readable views of the contents.


DialogDesigner is so far a design and test tool, and not a complete case tool in that code is not generated. In order to support implementation, formal grammar names and state names can be supplied in the designer window, and the prompts may depend on explicit, dynamic formal parameters.


A static version of the dialogue model can be generated as HTML, providing a readable report with transition links, comments, prompts etc. Together with test scripts and graphs, this provides documentation of what has been made in a way that non-experts have a chance to read. Of course, the electronic model itself is the designer and implementer oriented documentation.