Establish user requirements
The purpose of user requirements are to (1) translate the business requirements into a schematical structure of the application solution; and (2) describe HOW an end user is expected to accomplish a given task(s). User requirements should be based on a careful analysis of the target use population – their abilities and any limitations, as well as any naturalistic processes that may exist for the task(s). The tangible artifact is a user requirements document that can be either a graphical call flow or a written document, which ever is easier for all audiences (e.g., developers, testers, stakeholders) to comprehend. In essence, it is to be treated as an agreement between all stakeholders as to what will be developed.

An important and difficult step of designing an application is determining what the stakeholder actually wants it to do. This is because often the customer is not able to communicate the entirety of their needs and wants, and the information they provide may also be incomplete, inaccurate and self-conflicting. The responsibility of completely understanding what the customer wants then falls on the providers of the product. Once the required information is completely gathered it is documented, which is meant to spell out exactly what the application must do and becomes part of the contractual agreement. A stakeholder cannot add features not in the agreed to user requirements without renegotiating and a developer cannot claim the product is ready if it does not meet an item of the agreed to user requirements.

Establishing user requirements requires a good amount of collaboration and negotiation with stakeholders, project managers, developers, and testers to identify what is technically and fiscally feasible within the desired timeframe for application deployment. Developing user requirements documentation requires both technical and interpersonal skills.

Understand and meet users' expectations
Meeting user expectations is easier said than done. The VUI designer is often pressured to meet the business needs of the client, and user expectations can take a back seat. However, the client will quickly remind the VUI designer if the goal of meeting users' expectations has not been met. This is because clients track application metrics. Metrics such as hang ups, opt outs to agents, fail outs to agents, all indicate some degree of failure to live up to users' expectations.

The VUI designer should NOT assume the role of the user; the edict “Know they user, for they are not you” should be taken to heart. To understand and meet users' expectations for an application, it is necessary to involve prospective or actual application users. The focus should be to understand what tasks users would expect to accomplish for an application, as well as how they would expect to go about completing those tasks. Much can be learned early on through ethnographic observation, interviews, and contextual inquiries of target population users undertaking target or similar tasks – what information users would expect to provide to the system, what information they would expect to be provided as feedback, what task affinities exist, how long each task transaction would be tolerable, what sort of support should be provided to recover from errors, and how best to word prompts so they are clear to the target population.

The VUI designer should be guided by both quantitative and qualitative metrics in designing or tuning applications to meet user expectations. The resulting VUI design should be supported by the target standards for each metric. Where client business requirements run contrary to the VUI design, the VUI designer should persuasively argue that the design will meet or exceed target metric standards and will result in greater technology usage and greater successful task completions, resulting in reduced cost to the client and increased customer loyalty.

Involve users in establishing user requirements
“Know thy users, for they are not you”. This is an important edict. Users are subject matter experts who will complete a task based on their body of knowledge of the operational domain. Their level of domain knowledge is likely superior to yours. For this reason, it is critical to involve them in knowledge capture activities that will inform user requirements.

A large body of participatory design literature suggests the value of subject matter experts in the application design. As noted earlier, subject matter experts can provide valuable information regarding the users' mental model of the application. Further, they can provide feedback about their expectations for task objectives.

That said, callers are likely neither aware of nor care about stakeholders' business objectives. Nor are subject matter experts expert in human behavior (except for their own), so their perspective will be highly personalized.

To sum, users should be used to gather initial information about how to approach an application design and for feedback on design alternatives in the logic and prompting