VUI best practices - good or evil?

I came across this blog article on VUI best practices and standards when I was searching for people who were blogging about IVRs. The article points out that following standards can result in products that have a "me too" quality, something that you want to avoid if you're trying to differentiate yourself in the marketplace. This article pointed to a number of others on the topics of standards and best practices, including the GetHuman standard. There's always a lot of discussion among web and GUI designers on the subject of standards and guidelines, so it's no surprise that VUI designers hold strong opinions on the subject too.

First, some definitions. The VUI best practices article and those it references aren't talking about the same thing, and therein lies some confusion. In the narrowest sense, standards are technical specification that, if implemented properly, ensure interoperability. More generally, standards are published criteria against which a product or service are measured. You may design the most usable, functional, beautiful table lamp ever invented, but if the plug doesn't follow standards for electrical plugs and it doesn't fit into your country's wall socket then your product will fail in the marketplace. The HFES 200.4 Software User Interface standard for Voice Input/Output and Telephony is a set of recommendations that, if followed by IVR product developers, seeks to improve interoperability by presenting end users with a common set of interactions, terminology, and business processes regardless of IVR platform or application. This standard was derived from both data and common practice and was drafted and reviewed over the course of several years by a committee of industry practitioners. Standards are written to be unambiguous and easily interpretable by their users.

User interface design guidelines are suggestions and recommendations also derived from data and common practice. Any set of guidelines, even those that are well written, will have those that conflict with one another, and are subject to interpretation. For example, a common IVR guideline is that prompts should be clearly written and easily understood. Another common guideline is that dialogs should support the efficient completion of tasks. These are both good guidelines, but there's a tradeoff between clarity and efficiency, and part of the skill of a dialog designer is to strike a balance between the two.

"Best practices" could refer to nearly anything: standards, user interface guidelines, business processes, development process, fulfillment, metrics, the treatment of customers, etc. A lot of designers will insist (as I often do) that user-centered design is "best practice" for user interface design and development. The GetHuman standard mixes suggested best practice for business process with IVR design guidelines. So, back to the original topic: what are the dangers of VUI best practices and standards?

First off, a digression. Let's assume that the guidelines or proposed best design practices do provide, in fact, good design guidance and are interpretable by their intended end users: interface designers. This isn't always so. Case in point: some managers of a sales force with which I was acquainted had complained about the quality of the online applications that the sales force and the customers needed to complete to receive products and services. The sales force was required to handle applications for multiple lines of business, and each had its own ideosyncratic, de facto standards for creating applications. The look-and-feel of the applications were very different per line of business. A decision was made to standardize the look-and-feel of the various online applications. This was sold to the sales force in terms of improved consistency across the various applications and reduced training for staff - what you learned about the flow of one application applied as well to others. The online applications were sold to the lines of business as reducing paperwork in their back offices (the online forms replaced traditional paper applications). The standards were sold to the designers of the applications as reducing their work load. Some major design decisions were made for them, and the resulting constraints on their design meant that they wouldn't need to "reinvent the wheel" every time they had to design a new application. This is all motherhood and apple pie stuff, so far.

• The first danger of standards and guidelines: they can be so poorly written as to be unusable.

Unfortunately, the authors of the guidelines had created a document that was uninterpretable, even by experienced user interface designers. The guidelines were often arbitrary, vague, and conflicting. Moreover, QA was done by the guideline authors themselves, a situation that you avoid for the same reasons you split up development and code QA. The designers complained bitterly about the quality of the guidelines and of the QA process itself, but any feedback on the guidelines themselves were reacted to with defensiveness by the authors. This is a known issue among designers, and a number of sessions at conferences such as Usability Professionals Association are organized around how best to create usable recommendations and guidelines. End of digression.

But what if the standards and documented best practices are well written, consistent, and do in fact represent good guidance? That's a harder question. I think that's the case that the article VUI best practices and standards was addressing. I'll talk about that in my next blog entry.