Be Cooperative... Like Your Users

Actions on Google

Table of contents


Logic and accuracy don't always rule


Recognition grammar performance and repair (error) prompting go hand in hand


Varied user responses are opportunities, not “errors”


Like telling a joke—if you have to explain it, you’re doing it wrong


Natural conversation is time-tested and user-approved



Actions on Google

Conversation is a lot more than just a simple exchange of information.

Logic and accuracy don’t always rule Our verbal shortcuts reveal the often illogical, non-mathematical nature of conversation. “Sue has two kids,” for example, is technically and logically correct if Sue has five kids. But the statement is misleading in conversation, because it’s missing contextual information (Sue’s other three kids, in this case).

In conversation, we share natural assumptions about a topic. We know how a conversation should develop. We have expectations about the quality and quantity of the contributions that each person should make. On top of that, we roll in politeness, consistency, and other natural rules of conversation. Plus, everyone instinctively knows to disregard superficial meanings if they’re unclear or hyperbolic and search for deeper, non-literal interpretations. While we all do it naturally, conversation is a deceptively complicated process.

Plus, people can sometimes be deliberately uncooperative. In some cases, they’re only trying to be kind or polite. When asked how a prospect did in a job interview, for example, they might evade a negative reply by saying, “He wore a beautiful tie.”

Linguistics philosopher Paul Grice 1 said that to be understood, people need to speak cooperatively. He called this the Cooperative Principle. We can omit a lot of information by assuming there’s an undercurrent of cooperation, making a conversation significantly more efficient. Asking "Do you … ?" really doesn't mean "Say 'yes' or 'no.’" Rather, it’s often an indirect, polite way to ask something more specific.

A VUI has to accommodate all of these rules, which most people follow without thinking.

Recognition grammar performance and repair (error) prompting go hand in hand VUI designers also have to be able to anticipate certain types of human “errors,” as well as how a speech recognition grammar (everything a person might answer at some point in the conversation) is constructed. For example, consider this confirmation prompt for the purchase of a plane ticket:

The philosopher also created Grice’s Maxims to define basic rules of cooperative conversation: 1. Quality — Only say things that are true 2. Quantity — Don’t be more or less informative than needed

Alright, from Atlanta to Geneva on September 13th at 6 p.m. Is that right?

3. Relevance — Only say things relevant to the topic

If the answer is yes, people tend to give a short answer—“Yes,” “Yeah,” “Correct,” “That’s right,” etc. But when the answer is no, they typically don’t say just “no.” Instead, they’re cooperative, moving the conversation ahead with responses such as, “No, not Geneva, I said ‘Jamaica’” or “No, not the 13th, the 30th, three zero.” Or they might respond only to part of what they heard, “You got the time right, but the date’s wrong.”

4. Manner — Be brief, get to the point, and avoid ambiguity and obscurity In other words, people should be as truthful, informative, relevant, and clear as the situation calls for. This is something voice user interfaces (VUIs) also need to do to be effective. 1


Actions on Google

If a technical limitation prevents your VUI from accommodating such cooperative exchanges, the dialog shouldn’t set the user up to expect the system to be artificially capable of doing so. If it does, then first-level repair strategies are limited to unnatural prompts like: “So, did I get that right? Just say ‘yes’ or ‘no’”—instantly distancing the user and exposing the VUI’s underlying limitations and the artificial nature of the conversation, thereby undermining any potential for naturalness.

Let’s take a scenario in which a VUI needs to gather both a date and time. It should start out using a general prompt, which could work for both:

When a VUI isn’t designed to accept responses that correct, qualify, or add information, it may mistakenly convey that it regards such naturally cooperative verbal behavior as uncooperative. This linguistic misperception will invariably show up in the brusque or mechanical tone of some so-called “error” prompts, as if the person has misbehaved (“That was not a valid response.”), or in a tone of mock concern, as if speaking to a slow learner (“I’m sorry. I did not understand the response I heard.”)

But, since a more tentative or less-informative user might parcel out the information, the VUI doesn’t treat it as an error, but simply accommodates:

User VUI User VUI

User VUI User VUI User VUI

Varied user responses are opportunities, not “errors”

Set an alarm. Okay, for when? Tuesday at 6 a.m. Done. Your alarm’s set for Tuesday at 6 a.m.

Set an alarm. Alright, for when? Tuesday. And the time? 6 a.m. There! Your alarm’s set for Tuesday at 6 a.m.

The above exchange doesn’t expose the hidden logic needed to make the VUI cooperative and prepared for other possible user responses. The user could have completed the entire step with a single command without being prompted at all, giving either or both pieces of data, and it’s left to the VUI to interpret the missing information (“Set an alarm for 6 a.m. Monday morning,” “Wake me up in 6 hours,” or “Set an alarm for 7 o’clock,”)—all with elements left unspoken by the user.

Consider how a question could be framed to anticipate repair prompting while keeping the conversation on track without discomfort or distraction. In fact, such an instance can become an opportunity for another meaningful turn in the dialog. By now, because they’ve had bad experiences with speech-recognition technology—often compounded by bad VUI design—some people may take prompts literally, and not offer additional information that would be “naturally cooperative” to avoid triggering a recognition error. VUI design should comfortably accommodate these users as well.

The prompt “Alright, for when?” facilitates easy responses from people who have either a day or a time in mind, as well as from those ready with both. This kind of prompt fully facilitates the Cooperative Principle.


Actions on Google


Natural conversation is time-tested and user-approved

A good VUI focuses on the intuitive power of language and meaning, rather than showcasing how a computer can be programmed to take “commands.” It leverages the communication system that people learned first and know best: everyday speech. We’re already proficient in our own language, so we don’t have to be taught how to say an expected response or command in plain English (or plain Spanish, Tagalog, or Hindi). Put another way: Avoid commands as such, but if you need to help people understand what they can say to move the conversation along, use something intuitive.

The Cooperative Principle underscores our ability to communicate efficiently and in socially appropriate ways, built on a powerful shared base of knowledge. By leveraging the conventions of natural conversation instead of ignoring them, we can make far better VUIs that people intuitively know how to use and feel comfortable with.

So, instead of: To hear the message again, say ‘Repeat;’ to reply to it, say ‘Reply;’ and to move on to the next one, say ‘Next.’ Consider the more intuitive: Repeat, reply, or go on to the next one?

Best practices Remember these basic building blocks when creating a VUI:

→→ Understand recognition grammars and repair prompting →→ Accommodate diverse user speaking styles →→ Let people know what they can say, intuitively



Be Cooperative... Like Your Users Developers

fine basic rules of cooperative conversation: 1. ... tion prompt for the purchase of a plane ticket: Alright, from ... alog shouldn't set the user up to expect the system.

177KB Sizes 1 Downloads 81 Views

Recommend Documents

Beyond the Rack re-engages users on the ... Developers
a highly-engaged and commercially-valuable audience. Push notifications allowed us to bring one of the most compelling capabilities from our native app to our.

Developers Shouldn't Be Responsible For Security - Forbes.pdf ...
4/22/2016 Developers Shouldn't Be Responsible For Security - Forbes. 1/6. APR 21, 2016 @ 12:34 PM 223 VIEWS. Starting At.

Understanding Your App Users with Google ... Services
25B+. # of mobile apps on Google Play. # of apps downloaded from Google Play. Mobile app revenue1 expected by 2016. $46B. # of mobile apps on Apple iTunes ... Google Confidential and Proprietary 13. Slacker Radio: Beating ROI goals with analytics. 70

irongeek_adc I like your work archiving cons, but your ... -
Apr 1, 2015 - @0xabad1dea (also, everything vaguely related to tech has a feminism culture .... i didn't get. Me being a Data Admin for 7 years didn't count. 1.

PDF The Membership Economy: Find Your Super Users, Master the ...
The Membership Economy: Find Your Super Users, Master the Forever ... Subscription Marketing: Strategies for Nurturing Customers in a World of Churn.

I'm Trying to Be Like Jesus.pdf
B. 3. For. E. 0. and. 1. 3. deed. 3. Je. 3. things. F. 7. E. 0. 3. sus. are. 2. the. 5. Children's Songbook 78. Whoops! There was a problem loading this page. Retrying.

Contract Advisory Systems Developers and Systems Developers ...

UC Berkeley's Bicycle Cooperative
What we do: Our primary service is opening up our facility to the public several ... experience for the customer, but also the empowerment that comes from ... growing number of bicycle essentials for retail sale, including inner tubes, cables,.

Users Manual.pdf
OMEGA CMMS Users Manual ..... OMEGA MAINTENANCE (OmegaMaint) CMMS is a computerized solution for physical ... Work Order management system.

Beauty Survey Google Users
The survey was conducted online, through a web-based interviewing process ... advertising, permission-based databases, public relations, ..... Direct mail pieces.