The high-level design specification (HLD) typically takes the form of a call flow diagram. The purpose of this document is to provide both the designer and customer with a visual representation of the application. The HLD emphasizes the structural flow of the application and avoids detailed prompting and complex, low-level business rules. This document should represent the call flow and different paths callers could follow. However, it lacks the ability to illustrate any persona or prompting. With this level of detail, customers can evaluate the design to provide direction and feedback early in the design process. Once this document is complete, it provides a solid foundation for creating the skeleton version of the user interface specification.

What the high-level design specification lacks in illustrating prompting and persona, the conversations or sample calls document delivers. This document is composed of a series of scenarios that show the conversational experience between the caller and the system. Structured much like a movie script, each scenario demonstrates the turn-taking between the caller and the application as the caller performs self-service. The shortcoming is that a scenario can only exercise a single path of the call flow. Typically, only significant or the most exercised paths are included in the conversations.

The skeleton version of the user interface design document reflects the complete call flow, including every path through the application and all initial prompts. It is a “skeleton” in the sense that it excludes error handling, help prompts, synonyms, and database inputs and outputs. Unlike the sample calls, which contain only representative paths through the application, the skeleton is a complete version of the call flow, so all potential paths through the application are represented. Initial prompts are included, so evaluation of the prompts can be performed to ensure that they work well together and that transitions are smooth. Avoid including synonyms, error handling, such as retries or help, at this stage. Until the skeleton is reviewed with and approved by the client, further changes to prompts are highly probable, so effort to word anything other than initial prompts will result in rework.

Each of the documents previously discussed serve as stepping stones towards the full user interface specification. Once the skeleton version is approved, you can confidently fill in all remaining details necessary for the full specification. This includes all error handling, help prompts (if used), synonyms, database and web service information, global handling and overrides, and any further details. The end result is a document that defines exactly how each state behaves from every possible entry point to every possible exit point. Once the client approves this document, the design phase can effectively transition to the development phase, and complete prompt scripts can be generated for professional recording