PETER HODGSON: Hi, I'm Peter Hodgson.
I am an interaction designer working on conversations
with the Google Assistant.
And over the next few minutes, I'll
be describing the core pillars to be conscious of when
you're designing conversational experiences
and some hard learned design lessons.
But first, let's talk about conversation itself.
For many people who are new to designing and building
conversational experiences, this is the big question
in their mind.
I mean, you can talk.
I can talk.
How hard can it be?
Well, it turns out that we humans
have had a lot of practice with conversation.
Recent evidence suggests that humans have been conversing
for up to half a million years.
Researchers have discovered that the common ancestor
of Neanderthals and Homo sapiens had
the hyoid bone in their throat, which controls the tongue.
And conversation is inherently social and contextual.
Every one of us here has been practicing speaking
since before we could walk.
So it's literally instinctive to us,
which makes it extremely complex and subtle and hard to codify.
As a colleague of ours likes to say,
we don't have to think about conversation in the same way
that fish don't have to think about the water.
The key point for us all is that people
aren't going to change how they converse anytime soon.
So we need to design conversational interfaces
to match people's expectations.
We're teaching computers to speak human, not the other way
around.
The good news is that people have
been studying and researching language for a long time.
And we can leverage that knowledge
when designing conversational interfaces.
And when you're starting to design conversations
there are three ideas or pillars that I think
you should pin on the wall.
The first pillar is the cooperative principle
identified by the philosopher of language Paul Grice.
It describes the rules and assumptions we all
abide by in our conversations.
And we do so entirely subconsciously.
His maxims of quality, quantity, relevance, and manner
can be used as reliable guidelines
when you're creating conversations.
For example, the maxim of quantity
says that we expect participants in a conversation to
and I quote, "not make their contributions
more or less informative than is required
to advance the conversation."
And I'll bet you can all recall conversations
you've had with people who are not abiding by this maxim.
That's the person who talks too much
or the person who doesn't say enough.
So I encourage you all to study the cooperative principle
in detail.
If the cooperative principle deals
with the content or the fuel of a conversation,
then turn taking is the engine and the gearbox.
And it is the second pillar to bear in mind.
Turn taking is the mechanism by which
we resolve ambiguity and repair conversations in order
to progress to a final resolution.
Linguists will refer to people handing the turn
or taking the turn in a conversation.
And in the real world we use linguistic prompts--
questions or just body language--
to signify when the turn should be taken.
For the moment, Virtual Assistant
understand none of these subtle social cues.
So turn taking for conversational assistance
has to be more explicit.
And we have to manage this when writing dialogue so it doesn't
become unnatural or robotic.
The third pillar is to design conversations that
work for the user's context.
Talking to machines is still in its infancy.
And people still find it socially awkward.
So you should actively focus on the user's physical context
and the kinds of conversations they're
open to in that context.
And look to design for simple, intuitive, high value
conversations while people are in socially safe environments
and where voice interactions have less friction than touch.
So the three pillars are the cooperative principle, turn
taking, and the user context.
And here are my five top lessons learned.
First, persona-- designing your system's persona
is not a nice to have.
It's a must have.
There's another video in this series.
And it's a detailed talk about this topic,
which I encourage you to watch.
But it's worth highlighting here.
A persona is a style template for your brand.
You should design it and use it to provide
a common understanding and a reference for consistency
during every step of your conversational design
development.
As another colleague puts it, if you don't clearly
define your brand personas, then your users will.
Second-- and another must do--
start with the sample dialog--
whatever the platform, you'll be deploying on.
Create end-to-end sample dialogs for the most likely cases.
Writing the dialog will help you discover
more cases and the conversational logic
you'll need to build.
Don't just write the dialog.
Speak it out loud with someone else.
It'll change what you've written.
And present dialog to stakeholders
in the audio channel, not as written text.
You can record it using a TTS engine
and listen to the playback.
After you've nailed the most likely cases in the sample
dialogs, then design all the repair cases.
Designing for conversational repair
is the topic of another video.
But bear these things in mind.
We need to make conversations work
well when it goes off track.
These can be points of great user frustration.
And so if handled well, they're great opportunities
to rebuild user trust and confidence.
Your Assistants should be forgiving.
Remember, people are instinctively
trying to be cooperative.
But we're human.
And we make mistakes.
So we need to be highly focused on helping them get back
on track as naturally as possible.
And here's a top tip.
A key approach for identifying repair cases
is to prototype the conversation as early
as you can in the process.
Write and perform the conversations with real users.
And use "Wizard of Oz" techniques
with audio recordings to test your conversational structure
and dialog.
Next we're building a system for users
to access their Assistant anywhere.
So you must consider your conversational experiences
across modalities and surfaces.
In some cases, the conversational logic
might have to change depending on the surface.
For example, presenting choices to users on an eyes
free device, such as a Google Home
requires different dialog strategies
than when the user can pick from a list of choices on a screen.
And designing for multi-modal conversations with the screen
is hard.
The important thing to remember is
that in multi-modal conversations
the screen is only one output of the conversational state.
There's both audio and visual channels to be choreographed.
So think hard about the best channels
for information transfer.
What's best on screen?
What's best in audio?
Where's the right balance for your conversation?
In a multi-modal experience screens
are really great for presenting large amounts of information.
They're great for displaying touch avoidances
to repair or to progress a conversation more quickly
than with another spoken turn.
And the screens are useful for orienting the user and way
finding in a multi-step task.
Finally, with the Assistant you're
designing for use over time.
The second conversation with the user
will always be different from the first.
And the third may be different from the second.
We expect a conversational Assistant
to understand and remember us.
So the conversations should reflect that memory.
Just keeping track of previous conversations and a user's
context and adjusting the conversation
based on these cues will increase
the perception of an intelligent agent significantly.
So design your persona.
Always start with the sample dialogs.
Repair with context sensitivity.
Design cross platform from eyes free to multimodal.
And design for frequency.
And never forget the cooperative principle.
Good luck with your conversation design.
And thanks for listening.