Published on | Prototyping: From UX to Front End — Medium Cam Sackett

Voice Experience Design

UX Knight

Introduction

Designing for a VUI (voice user interface) is different from how we design for a GUI (graphical user interface). Yes, designing for Voice is different. However, the Voice Experience Design is not; User Experience Design principles still translate well.

Interfaces may change but how we design for them does not. We adapt. Design principles are not interface specific.

I highly recommend diving into VX Design. With Voice, visuals are eliminated and the experience is exclusively vocal and auditory — we focus on how people naturally communicate with their voice. We can gain vital insights by implementing this design constraint which can be converted into any type of interface or product.

I set out to make my first Alexa Skill and have documented my process.

Storytelling and Role Playing Games

You will find throughout this case study that most of my design process will be familiar. For voice, I chose to focus on storytelling. My Alexa skill is influenced by my love of adventure role-playing games like the Legend of Zelda and my passion for design.

Goal

I wanted to design a skill specifically for designers which is hopefully useful and delightful. I call it UX Master Quest. The first version is for Voice interfaces and is merely a proof of concept. The basic idea is that the UX Knight travels through the land of Complexity solving problems. Instead of casting spells and magic like in traditional RPGs (role-playing games), the UX Knight uses UX laws and design principles to combat foes and collects UX items along his/her journey.

Good RPGs have story elements, UX design utilizes story elements so I wanted to include story elements into my Alexa Voice Skill.

Seven elements of storytelling

The Premise: The concept of the story. What’s the point. What is the reason for the story.
Protagonist: Most stories have a main character or hero/heroine. (In UX, it’s the people using your service or product).
Antagonist: The main role of the antagonist is to stand in the way of the protagonist. The antagonist is the opposing force. Usually, the story ends when the protagonist defeats the antagonist.
Conflict: It introduces a problem or challenge (something we love as Product Designers). The conflict provides the protagonist a good reason to say or do something important. It is a crucible in which the protagonist can grow and change.
Structure: A story needs a beginning, middle, and end. (This story structure works well with a typical customer journey map or the life-cycle of a product).
Invoke Emotion: The power of storytelling is often unleashed when it invokes emotion and motivates us to find a solution.
Sharing: Good stories are told and retold. (This applies to UX design. If your customers share their experience with your service or product, that’s a very good thing).

UX Master Quest

Setup

Before I began doing any flow diagrams, scripts, use cases, etc., I had to establish a Premise. Thinking about the Alexa Skill’s description helped set up the story. The introduction went through various iterations. What started out as “Enter a land where the users have bad experiences and your quest is to become a UX Master” turned into the following:

Enter the land of Complexity where the usability is cursed and people’s experiences are terrible. You are the UX Knight! Your quest is to conquer the Problem Dragons and become the UX Master.

This final introduction derived from determining story elements:

The Protagonist is you. You or the person interacting with the Alexa Skill are the UX Knight.

The Antagonists are the various Problem Dragons throughout the land.

The Conflict is the land which is cursed with poor experiences. The UX Knight grows and changes as he/she defeats each Problem Dragon and gains more UX design experience.

For the Structure, I actually sketched a map which gave me more direction and helped establish the story’s beginning, middle, and end.

The challenges that the UX Knight encounters throughout the quest provide delight as well as motivate him/her to find a solution—I think games help us learn better—this is a user friendly and fun way to learn UX Laws and design principles.

Story Flow

From here I did a basic flow diagram. I think of these as road maps. You can get an overview of the beginning, middle, and end as well as the choices one can make while on that road.

VUI documentation

A VUI (Voice User Interface) documentation is basically a way to list out all of your intents, utterances, slots, and other Alexa Skill details. What are those things you ask?

I’ll let Amazon’s voice design guide explain:

Intent: “The main request or action associated with the user’s command for a custom skill. For example: “Alexa, ask History Buff what happened on June third.” In this statement, “what happened on June third” maps to a specific intent that can be handled by a particular Alexa ability. This tells Alexa that the user wants “History Buff” to get historical information on a specific date.”

Utterance: “The words the user says to Alexa to convey what they want to do, or to provide a response to a question Alexa asks.”

Slots: “an argument to an intent that gives Alexa more information about that request. For example: “Alexa, ask History Buff what happened on June third”. In this statement, “June third” is the value of a date slot that refines the request.”

Here is an example of what that documentation looks like.

UX Master Quest VUI Documentation

User Scripts and Use Cases

Once I had my base setup, I could build user scripts and use cases.

Scripts are basically writing down what the conversation would be like between a person and an Alexa Skill. It’s important to write these out and preferably vocalize them with a friend—make them sound natural.

Here is my first draft of User Scripts and Use Cases.

<a href="https://medium.com/media/d2caded689c83df5c7b038a899237df0/href">https://medium.com/media/d2caded689c83df5c7b038a899237df0/href</a>

For me, writing scripts is where most of the voice design and iterations occur. I went through dozens of iterations. Iterations are key to designing for any interface. You’ll see more on iterations later. Scripts are when you practice reading aloud with other people. I consider them low-fidelity prototypes.

Here are two good resources for voice design from Amazon and Google:

Amazon: https://developer.amazon.com/designing-for-voice/

Google: https://developers.google.com/actions/design/

I used some design principles from Alexa’s Design Guide and included conversational components from Google’s Design Guide.

Providing definitive choices

“You can reach the troll faster by applying one of the UX design principles in your bag. You can use Hick’s Law, Miller’s Law, or Jakob’s Law. Which UX law will help you get to the mountain troll faster?”

Prompting with guidance for the user.

“You can enter the Caves of Uselessness to the north or climb the Mountains of Desolation to the west. Where would you like to go?”

Acknowledgements and confirmations

“You’ve entered the Caves of Uselessness.” or “Excellent choice!”

When designing for voice these design guides should be kept in mind and are a good resources to reference from time to time.

Here is the final draft before I went to a high-fidelity prototype.

<a href="https://medium.com/media/75c2a6d0f0f71a26182b4e91ca3d14fa/href">https://medium.com/media/75c2a6d0f0f71a26182b4e91ca3d14fa/href</a>

High-Fidelity Prototype

This is where I really focused on speaking and writing naturally as well as deep diving into how the user will interact with the voice skill. I inserted pre-recorded audio to enhance the voice experience as well as incorporating SSML (Speech Synthesis Markup Language). SSML allows you to give wider range of natural expression. For example, you can have Alexa whisper, spell out words, take longer pauses, adjust the prosody such as modifying the volume, pitch, and rate of tagged speech, and much more.

Iterations

For example, let’s take Use Case 3 where the UX Knight applied the correct UX design principle, recovers their map, proceeds to the top of the mountain, and encounters the Problem Dragon.

One of the first iterations
Alexa: You got your map back. Oh no! The Dragon is coming toward you. You can battle the Problem Dragon or run away? What would you like to do?

First Draft Version
Alexa: You have recovered your map from the mountain troll and have arrived at the top of the mountain. Don’t rest yet! You’ve encountered the Problem Dragon atop of the Mountains of Desolation. You can choose to battle the Problem Dragon or run away. What would you like to do?

Final Draft Version
Alexa: Hurray! You have recovered your map from the mountain troll and have arrived at the top of the mountain. But wait, (insert Dragon audio) watch out! The Problem Dragon approaches! You can choose to battle the Problem Dragon or run away. What would you like to do?

High-Fidelity Prototype version (Javascript)
Alexa: <say-as interpret-as=”interjection”>Hurray!</say-as> You have recovered your map from the mountain troll and have arrived at the top of the mountain. But wait, <break time=”.2s”/> <audio src=”https://s3.amazonaws.com/ux-master-quest/Audio/Dragon.mp3” /><say-as interpret-as=”interjection”>watch out!</say-as> The Problem Dragon approaches! You can choose to battle the Problem Dragon <break time=”.3s”/> or run away. What would you like to do?

Here is a run-through of the high-fidelity prototype:

<a href="https://medium.com/media/59a9ff0ab9055313ee83946cbd282059/href">https://medium.com/media/59a9ff0ab9055313ee83946cbd282059/href</a>

As you hear in the video, the SSML enhances the voice experience and makes Alexa sound a little bit more natural (albeit cheesy at times). The final step is to test your prototype.

User Testing

I did user testing throughout the entire process—not just at the end. The user testing I did with the scripts led me to make many many changes as I vocalized the scripts with friends and family. I learned that some of my initial iterations were confusing to some of the people that tested my initial script drafts.

Testing with the high-fidelity prototype helped bring things together, especially the SSML additions. Initially, I thought my audience was too narrow (Designers) but I was gladly surprised that people who were not Designers understood the skill even thought they may not know the design terminology or definitions of UX Laws. This is due to having an iterative design approach and user testing.

Overall, testing is helpful because it helps to account for what a person may say in the utterances which can prevent a lot of poor experiences. It also helps you gauge whether your voice interactions feel natural or not—whether they flow smoothly or not.

Conclusion

The biggest take away from designing for Voice is how it overall, improves the way I design and how it magnified my awareness of subtle interactions that sometimes get overlooked with visual or tactile products. I love the constraint of only designing for voice—it forced me to think a little deeper about accessibility and usability as well as empathizing more earnestly with people.

For the next design, I want to design a visual version and interactive game of UX Master Quest (currently in the works—look for it in the future).

For me designing for voice can be a “design methodology” in and of itself without ever making an actual Voice product. VX Design helped me generate more ideas. I think if one is designing for an app or website or other product, simply incorporating the “idea” of designing for Voice will open a lot of doors.

Although limited at the moment, I think Voice is one the most human interfaces that has the potential to reach the ideal of a truly human-centered-design experience.

<a href="https://medium.com/media/b85dfbb5286d8a25cf2e754b9462cf45/href">https://medium.com/media/b85dfbb5286d8a25cf2e754b9462cf45/href</a>

UX Master Quest was originally published in Prototypr on Medium, where people are continuing the conversation by highlighting and responding to this story.

UX Master Quest

Cool stuff, every week

More Articles