Several deliverables communicate system requirements, ensure the design is on the right track, and help the customer understand the caller experience. The first deliverable is the requirements document. The requirements document consists of what the system should do, but the details around how it should be implemented are saved for the later design deliverables. It’s a good idea to assign a unique identifier to each requirement for traceability. As the design is created, it’s helpful to trace a requirement with the unique identifier from the requirements document to its location in the user interface spec, thereby ensuring all requirements have been covered.

Before jumping into a full-blown user interface specification, consider a high level design deliverable; it bridges the gap between requirements and the final design. The high level design document consists of a high level call flow and a set of sample conversations illustrating key paths of the modified system. Showcase a couple high traffic paths, as well as a couple of error recovery examples in the sample conversations. The earlier the sample conversations are written, the better. If the customer can visualize the designer's intentions early on, it’ll prevent the designer from getting all the way through the design only to have the customer require a major overhaul to the full design.

The next step is the full-blown user interface specification. The user interface spec has many different formats: Word documents with tables, Visio call flows, Excel spreadsheets, etc. See User Interface Specification for more details. This document should cover every possible aspect of the design, from prompt wording, to error prompts, to transfer strategies.

If the system goes through usability testing, a usability report should be delivered. The report should outline the usability process, scenarios, questionnaires, participant characteristics, etc. This is also where the usability findings and associated recommendations will be detailed, along with an estimated level of effort to aid in prioritization. For more information on usability testing, see Usability Testing and Wikipedia).

Although the requirements traceability matrix isn’t necessarily a client deliverable, it is a useful way to ensure that all requirements have been covered in the design. A spreadsheet may be used to list each identifier from the requirements document, along with its associated location in the design specification.

Not all of the mentioned deliverables require client approval. At a minimum, the requirements document and user interface specification should be approved by the customer. The high level design and requirements traceability matrix are important, but whether they are client-facing documents requiring approval is a matter of preference.