Voice User Interface Design VUI

I was recently reading an article about the future of wireframes in the context of user interface design documentation. Wireframes have been used mostly for visual elements and became a critical building block in the early days of the web.

But since I like drawing analogies between other UI fields and the VUI field, there were a few quotes that struck a cord because of their universality:

“The object was to create as many wireframes as possible, of every screen in the entire site, in big, monolithic and hugely detailed chunks. Rather than exploring different approaches to the information and structure of the site, the emphasis became entirely focused on using all of the time available to build a collection of wireframes, regardless of whether they were the right wireframes.”

Ouch, how much of that is still taking place nowadays? You create as many “detailed individual states” as possible sometimes loosing track of the real intent of the document. Nevertheless, some of those risks can be lowered by using a layered approach where you start as simple as possible and then start adding details to the design that make sense from a design perspective and that help clarify the overarching intent; for example: starting with a high-level, 1-page interaction flow, then adding details in the form of sample calls, which then evolve into detailed flows and become the source for an initial or “skeleton” specification document (containing mostly initial interactions, without error strategies) which after various reviews (including Usability) become a complete or “full” specification document.

“Why hold the information in a document that’s no one wants to read?”

Thank you, thank you, thank you. How many times designers have to create alternative “views” of their documents because some groups may not be able to use (or care) about certain aspects of the design, which might be buried with other details or is presented in a format that is neither usable nor efficient. But of course, the question that begs to be answered is “What’s the ideal document the developer would like to see to build a system from?.” Suggestions anyone?

“In a previous life at a big ‘old style’ new media agency, there often seemed to be a one tool fits all approach to projects. This applied to information architecture too.”

I’m sorry to say some of might still be living that life. Methodologies/Systems anyone? I totally agree with the notion of finding out what’s the best tool for a particular project. Not every project requires the 12-step program, and not every customer processes information the same way.

“The best sites are those where there’s a seamless divide between the look, the content and the experience.”

This one I would like to borrow and extend as a closing statement: “The best systems are those where there’s a seamless divide between the look, the sound, the content and the experience.”

Time to rethink our current documentation practices…