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.

A "Retreat from Saigon" project moment

Those of us born before 1965 or so probably remember the pictures of the chaotic evacuation of Americans and a few of their allies from Saigon in 1975 shortly before the liberation of South Vietnam. Those who had their tickets punched were able to board a helicopter bound for the safety of an off-shore aircraft carrier. Many others were left to their fate. The Retreat from Saigon became a metaphor for any hasty, disorganized end to an ill-advised adventure.

Toby Dodge, an Iraq expert at University of London, resurrected memories of the Retreat with his observations on the construction of the new US embassy in Iraq.

"A fortress-style embassy, with a huge staff, will remain in Baghdad until helicopters come to airlift the last man and woman from the roof," he said, adding his own advice to the architects of the building: "Include a large roof."

I've thought about the Retreat from Saigon at times during projects when it becomes clear to everyone (except a couple of reality-challenged project backers) that the project is going down. Key people with the political connections to do so announce that they've been reassigned to a different, higher-priority project. Managers who talked for weeks about "our" project and "our" decisions start talking about "your" project and "your" decisions. Contractors are abruptly removed and thanked for their efforts, or disappear without explanation. Those are the folks who had a seat on their helicopter. I've usually been one of the unfortunates who have been left on the roof, waiting for the chopper that never arrives.

That's project life. If you've worked projects long enough you've probably had your own Retreat from Saigon moments.

How to make innovation programs successful

More lessons from The Ten Faces of Innovation by Tom Kelley. In addition to the nuts-and-bolts of "doing" innovation - for which there's no cookbook anyway - Kelley addresses in a positive way things that companies need to do in order to make innovation programs work. Most of what he recommends would require changes on the part of a management team in the company. In my experience that's the hardest part of the program.

Kelley on how to make innovation work:

How to Cross-Pollinate

1. Show and tell. The IDEO Tech Box, a collection of hundreds of promising technologies, is a systematic approach to collecting and sharing what we know.
2. Hire people with diverse backgrounds. Sift through the job applications looking for someone who will expand your talent pool or stretch the firm's capabilities.
3. Create multidisciplinary project rooms and create lots of space for accidental or impromptu meetings among people from disparate groups.
4. Cross cultures and geographies. A well-blended international staff seems to cross-pollinate naturally from other cultures.
5. Host a weekly speaker series. Nearly every week, a world-class thinker shows up to share their thoughts with us.
6. Learn from visitors. Listen to what clients or prospective clients say about their industry, their company, their point of view.
7. Seek out diverse projects. A broad range of client work allows you to cross-pollinate from one world to another.

How to Build Better Teams

1. Coach more, direct less. Good executives and managers inspire their staffs to develop their confidence and skills so they can seize critical "big game" opportunities.
2. Celebrate passing. Break teams into smaller groups of three to six to increase the number of triangles where team members can pass ideas and responsibilities.
3. Everybody touches the ball. Find one or more responsibilities for every player.
4. Teach overlapping skills. Create opportunities for team members to assume nontraditional roles and push forward initiatives. Find out team members' unique passions and interests and put them to work.
5. Less dribbling, more goals. Encourage the sharing of ideas and initiatives. Solo dribbling can give a project the critical first push, but then you need teamwork to bring a project home.

How to Set Expectations -- the Seven Questions Every Company Should Ask Itself Before Launching an Innovation Program

1. How will your company define a successful innovation program?
2. How will your organization fund the innovation process?
3. What corporate resources will be available to support your effort?
4. How often will the stakeholder groups meet to review your innovation propositions?
5. How many task teams will you sponsor yearly? How often will you put together these teams?
6. How much logistical support will be given to your innovation staff?
7. What rewards or recognition can people expect for participating in this program?

Good stuff. Kelley, as program director at IDEO, has obviously lived through the scenarios he describes in his book, and his recommendations for doing innovation is spot on.

I was working on a small self-initiated project to introduce some innovation concepts to a company that I worked for. One of the team members asked, "how do we get this company to think innovatively?" I said, "how does this company treat people who try to innovate?" We talked about the existing reward structure for innovators (none) and the likelihood that the person would wind up in trouble for trespassing on someone else's turf (high). It's all about the system of rewards and punishments, folks. All of the "innovation camps" in the world can't overcome an environment where innovation and design is punished.

Tips for effective brainstorming

Previously I had written about Tom Kelley's fine book, The Ten Faces of Innovation. Some of the points Kelley makes about how to innovate effectively were excerpted in an article by BusinessWeek.

I must say, BusinessWeek really gets it when it comes to writing about innovation. They know who to talk to and how to extract the important stuff the innovators are trying to get across. For the most part, they recognize hype when they see it. Here are some of their lessons from Kelley's book.

Seven Secrets of Effective Brainstorming

1. Sharpen your focus. Focusing on a specific latent customer need or one step of the customer journey can often spark a good ideation session.
2. Mind the playground rules. Go for quantity, encourage wild ideas, be visual, defer judgement, one conversation at a time.
3. Number your ideas. Numbering your ideas motivates participants, sets a pace, and adds a little structure. A hundred ideas per hour is usually a sign of a good, fluid brainstorm.
4. Jump and build. You may have a flurry of ideas, and then they start to get repetitive or peter out. That's when the facilitator may need to suggest switching gears.
5. Remember to use the space. Write and draw your concepts with markers on giant Post-Its stuck to every vertical surface.
6. Stretch first. Ask attendees to do a little homework on the subject the night before. Play a zippy word game to clear the mind and set aside everyday distractions.
7. Get physical. At IDEO, we keep foam core, tubing, duct tape, hot-melt glue guns, and other prototyping basics on hand to sketch, diagram, and make models.

How to Build an Innovation Lab

1. Make room for 15 to 20 people. Even if the core project teams will be small, you'll want to share the results (and even work in process) with lots of your colleagues.
2. Dedicate the space to innovation. Your creative efforts need to live on without scheduling or moving.
3. Leave ample wall space for sketch boards, maps, pictures, and other engaging visuals. Don't use delicate surfaces or precious materials that would inhibit maximum creative use of all vertical and horizontal surfaces.
4. Locate your lab in a place convenient to most team members. Make it near enough for even part-time team members to drop in...but far enough away so they can't hear their desk phone ringing.
5. Foster an abundance mentality. Stock the lab with an oversupply of innovation staples: prototyping kits, Post-Its of every size and color, masking tape, blank storyboard frames, fat-tipped felt markets for drawing, X-Acto knives, and so on.

How to Observe with the Skill of an Anthropologist

1. Practice the Zen principle of "beginner's mind" -- they have the wisdom to observe with a truly open mind.
2. Embrace human behavior with all its surprises. Don't judge, empathize.
3. Draw inferences by listening to your intuition. Don't be afraid to draw on your own instincts when developing hypotheses about the emotional underpinnings of observed human behavior.
4. Seek out epiphanies through a sense of "vuja de." Vuja de is the opposite of déjà vu. It's a sense of seeing something for the first time, even if you have witnessed it many times before.
5. Search for clues in the trash bin. Look for insights where they're least expected -- before customers arrive, after they leave, even in the garbage. Look beyond the obvious, and seek inspiration in unusual places.

I watched a company go through the process of trying to learn how to innovate. They got the physical part mostly right: they cleared a lot of dedicated space and put new equipment and comfy chairs in those spaces, and designated people as "creative types" to use the space to "innovate." It was the process stuff they couldn't get right. The "creative types" revelled in their positions as company-designated innovators, were extremely territorial, were rigidly inflexible in their approach to problem solving, and shot down the ideas of others who weren't part of their in-group. If customers were consulted at all, it was only as a way of legitimizing the creative types' own opinions of what needed to be created. The managers in charge seemed to be oblivious to the fact that the creative types had no real committment to innovation other than as a means of promoting their own agendas.

Bottom line: Creative types have a duty to create and innovate. Managers need to learn enough about the innovation (or design) process to recognize the proper behavior, reward the good and discourage the bad.

Remarks on The Ten Faces of Innovation

I'm reviewing another favorite book, The Ten Faces of Innovation by Tom Kelley. Kelley is the general manager of the design shop IDEO. This is a thoughtful book about the innovation process that is different from any book about innovation on the market today. I read this one two years ago, and I still go back to it occasionally.

The book describes the 10 personas, or roles, that designers can play on a project. These are not job categories, but describe the different tasks that need to be performed in order to move an innovation effort forward. The Anthropologist is the field worker who looks for insights about consumer behavior by observing people and collecting qualitative data. The Experimenter creates prototypes of potential products and tests the prototypes with potential customers. The Hurdler is the person who is able to overcome obstacles in order to get the effort completed. The other roles include: The Collaborator, The Director, The Experience Architect, The Cross-Pollinator, and The Storyteller. Each role description is backed up by case studies that illustrate the role in action.

Some of the role descriptions require education and training to perform properly. For example, The Anthropologist and Experimenter tasks are part of most Human Factors analysts’ education and training. Other roles described in this book, such as The Hurdler, reveal an approach to getting work done that is not specific to any discipline. The book stresses the need for collaboration and describes what effective collaboration looks like. The author cautions against relying on a single expert or guru to deliver an innovative solution; something that seems to me to occur in companies far too often.

The author spends a good deal of time abusing those who play the pernicious role of The Devil’s Advocate. These are the people who attack others’ ideas during brainstorming sessions without taking responsibility for their actions. Kelley claims that The Devil’s Advocate is the single biggest innovation killer. It appears to me, having watched people play this role in so many project meetings, that there are more people playing this role effectively than the other 10 roles combined. Kelley offers practical suggestions for overcoming the negative effects of The Devil’s Advocate.

BusinessWeek carried an article about the IDEO innovation process in its Nov. 7 2005 issue that is derived from some of the advice given in the book. If you subscribe to BusinessWeek, you can access the article by clicking the provided link. I should say, as someone who has participated in and facilitated brainstorming sessions, that some of the ideas presented in this article seem obvious on their face but are often extremely difficult to put into practice.

http://www.businessweek.com/@@oPQwRIUQya5gowgA/magazine/content/05_43/b3956151.htm
If you can't follow the link I'll excerpt part of the article in my next blog entry.

Remarks on The No Asshole Rule

If you work in a company and are concerned, depressed, appalled, or bewildered by the mean spiritedness you see in your workplace, then this book, The No Asshole Rule, is for you. Robert Sutton, professor of management science and engineering at Stanford University, has written a remarkably readable little book about corporate culture and the morale-busting lack of civility in the workplace. More than simply making the workplace an unattractive place to conduct one's business, Sutton tries to show how the behavior of "assholes" - and he's pretty clear about what defines one as an asshole - actually hurts productivity and detracts from a company's bottom line. Hence, a few enlightened companies have adopted some form of a "no asshole rule." No one, no matter how productive or otherwise valued, is allowed to behave cruelly towards others.

I could go on and on about the things I like about this book, but it would be better for you to read the book yourself. Highly recommended. Read it now: Robert Sutton, The No Asshole Rule: Building a Civilized Workplace and Surviving One that Isn't. Warner Business Books, 2007.