Pancake Plaisir is an Alexa Skill that helps people find and prepare tasty and indulgent - but quick - pancake meals using their voice.
“Hey Alexa, Open Pancake Plaisir and find me some pancakes for breakfast!”
Overview
| Amazon Alexa Developer Console
My Process
I used design thinking and best practices for VUI design to guide the design of Pancake Plaisir.
Understand
Brief
To understand the problem I referred to documentation provided within the brief which clarified the problem, need and key findings from the competitive research. This gave me a platform to dive into the problem space and interpret the brief.
Key Assumptions
I contextualised the problem, viewing it from the perspective that:
Most cultures have a sweet and savoury pancake
Most cultures have some form of sweet or savoury pancake. Pancake Plaisir could serve as a useful encyclopaedia to celebrate the diversity of pancakes.
Pancake ingredients are simple
The ingredients for pancakes are typically considered household staples and are often available in the pantry.
You can get very creative
Pancakes afford a lot of creativity where people can really customise their pancakes to what they like
Visualise
User Personas
I noted down my assumptions about potential users to create 2 proto-personas that would guide the design direction and make Pancake Plaisir more accessible.
I validated my assumptions by conducting 2 interviews and used the information to adapt the proto-personas.
Key Insights
Key Insights
I had direction for designing for a busy professional and for an an older person with arthritis, both are interested in eating well and making quick simple food.
For my second proto-persona I identified that hearing the recipes took the strain off their eyes and that the more tired their hands became, the more fiddlier it would be to use a device, like a tablet, so voice offers an alternative path for following a recipe.
System Persona
Using my user personas, I moved onto creating the system persona - i.e. the persona of the skill. I needed to make sure that the system persona would suit my proto-personas, otherwise this could lead to a jarring experience.
Key Insights
Key Insights
The system persona would be like a knowledgeable friend or relative.
Humanising the persona is important as people generally ascribe human attributes to devices using voice. The system persona would be like a knowledgeable friend for my primary proto-persona and a helpful, caring nibling for my secondary proto-persona.
Placeona
To effectively design for voice we need to understand the context of the user, so I defined a placeona which describes the setting in which the voice experience will take place.
I needed to answer questions like:
Key Insights
Key Insights
The skill may be used in the kitchen or living room, tucked away, probably when their main attention is elsewhere.
I identified the common and somewhat idealised uses cases:
- During cooking when hands and eyes are busy, but ears and mouth are free - in the kitchen
- When trying to find a recipe, the quick VUI search cuts through complexity even if hands and eyes may be free - in the kitchen or in the living room
User Stories
Reviewing the personas, I identified the needs matching them to functionality the skill should include.
Key Insights
Key Insights
From this I established the intents of:
- Find recipe by meal type
- Find recipe by ingredient
- Receive random recipe
- Rate recipe
Writing and then grouping the user stories helped me to establish the intents (i.e. the functionality) and then prioritise them.
Recipe Database Creation
My skill would not be complete without recipes the user can access, so I created a database of recipes that could be grouped according to breakfast, lunch, dinner and snack. I also included a category for dessert as identified during my research.
Key Insights
The recipes would require tweaking to better accommodate a voice experience.
Though outside the scope of this particular iteration, I knew I needed to adapt the recipes to reduce cognitive load on short-term memory to support users in cooking the recipe.
Execute
Sample Dialogues
From the prioritsed user stories I wrote sample dialogues which would help me to explore the interaction and dialogue between the user and system. These are my first initial thoughts of what the conversation could be like between the user and system.
Opening Pancake Plaisir
Here I explored how the system greets the person. For example, is there a menu? Might the primary assumption be that the user wants a recipe? Is that a recipe for dinner or any recipe?
New User
Returning User
New User
Returning User
To help me I also role-played them and read them out to observe how they sounded in speech.
Sample Dialogue
Sample Dialogue
Key Insights
Key Insights
I identified that I needed to take the user’s context into account with the system greeting.
I was able to see I’d need different greetings and menu options depending on if the user was a new or returning user - and indeed how frequent a returning user.
The user can find a recipe using a specific ingredient.
The user can find a recipe for a specific meal like breakfast or dinner.
The user can find a random recipe - i.e. they don't state an ingredient, cuisine or meal type.
Once the user has tried a recipe, they'll be able to leave a rating. This helps the skill learn more about the user.
The sample dialogues helped me to explore the system’s voice and convey my initial thinking for logic.
User Flows
Using the sample dialogues as inspiration I began to work out the logic of the system. This meant working out how the system responds to the user and how it handles errors and repair paths. For example if the user does not answer a question the system has asked, what does the system do next?
Finding Recipe by Meal Type
This enables people to ask for a specific recipe for {breakfast} or for {dinner}.
Key Insights
Key Insights
It reinforced to pursue happy paths that are simple, but that are not too restrictive and cause errors later.
I initially identified a way for the system to assume for the user the meal type they want based on the user’s time of day. I later decided that this might be overly restrictive - what if the user wants it for tomorrow morning instead and not this evening?
I explored the logic of rating a recipe with first noting the happy path.
I was able to see that I’d need various pathways through for helping the user select from previous recipes, as well as error handling. For example the user might say an out of range star rating or they might include the recipe up front in their initial utterance.
When finding a random recipe, this is method that is the least controlled by the user (no meal type, ingredient etc).
They might include the recipe up front in their initial utterance.
Script
With the flows and logic defined, I wrote out the script. The script here represents the conversation between the user and system and all the possible responses the system might output, including error handling and help. This forms the interaction model of the skill.
Here I put my linguistic background to great use and validated the design against conversation design principles to improve the script. An example of this is through discourse markers to mimic conversational speech.
Poor Discourse Marker Use
Better Discourse Marker Use
Poor Discourse Marker Use
Better Discourse Marker Use
Key Insights
Key Insights
I needed to build more variety into the script to avoid repetitive dialogues.
By role-playing the flows and evaluating them, I observed I include logic to prevent repetition of the same discourse marker. If everything the system says begins with ‘So’ this may undermine the users’ perception of the system.
I began to write the script and wrote what sounded natural. This meant reading the lines back to myself.
I aimed to include a variety of system responses through:
- The use of discourse markers
- Rephrasing first prompts
- Summarising any subsequent reprompts
I also checked it against the user flows and sought to include more logic that would support the user during their experience - particularly for error handling.
I was able to see that I had included reprompts for user input, but there were gaps in for example how to handle no user input, so I added logic to catch this.
The initial designer noted it confused her for a moment, but soon recovered and understood the context of the page. Other people did not indicate confusion.
Usability Testing
With the script finished (for now) I prepped for usability testing. I used Wizard of Oz testing as a method to quickly evaluate the early design.
I used Wizard of Oz testing as a method to be able to quickly evaluate the current design.
Testing Goals
Script Accuracy
Navigation
Errors
Opportunities
Key Insights
Rating a recipe produced a wide-range of utterances, especially conversational ones such as “Tell it I liked that recipe”.
I had not anticipated that users may be so conversational with the system when rating a recipe. However I was also not confident that they would use a direct imperative, like “rate recipe”. I therefore need to account for more differences in use of language depending upon locale, age, gender etc.
Positive Feedback
Positive Feedback
Participants noted their ease at interacting with the virtual assistant.
The system’s language received positive feedback for its clarity, simplicity and prompting. This was reassuring to hear, given the lack of confidence and feelings of disappointment the participants mentioned feeling with virtual assistants.
For this iteration of testing, as it was early days in the design, I chose to use Wizard of Oz testing using a low-fidelity prototype.
How low is low? I would be starring in the role as the system and role playing the interaction with my participants over Zoom/Skype.
Taking part in other usability tests, I feel that my own are less specific and involved, but weaving the persona into the narrative of the script early prepared the participant for the role and task
Here are 2 examples of the scenarios for particpants. I aimed to use scenario tasks and use language that would not lead the participants. I was aware that they might mirror my language.
I recruited participants from my network with a range of familiarity with Alexa.
This would help me to see how the current design supports both novice and expert users.
Additionally, I made sure that I could test the design for both proto personas.
I was able to gauge their initial impressions and dive into ‘why’.
The tasks score quite highly overall. Scenario 3 and 5 are a little lower because the participants wanted to be able to offer more information up front when adding a rating and be able to ask for more information about a recipe.
User wanted to save the recipe and send the details to their phone - when only one option permitted
Include more specific help prompt that covers when users request multiple options when only one can be selected
Requesting more information about an exotic recipe
Add a description for recipe to make sure users can make an informed choice
Mental model mismatch for finding recipes, especially random recipes
This requires more thorough research and planning before acting on in this iteration
No utterance matching “I liked the {recipe name}” to add a rating
Add utterances similar to this to allow the user to access the rating functionality
Reviewing the issues raised from this usability test and prioritising them, I recommend the following course of action:
Enable users to provide more information up front when adding a rating - do not prompt the user when they have already supplied the information
User UtteranceEnable users to ask for more information about a recipe if they don’t know what it is
User UtteranceReviewing the issues raised from this usability test and prioritising them, I recommend the following course of action:
When users ask for more recipes, present 2 options to them, rather than 1 and test again to see reception.
SystemFor implementation, only one action can be taken, so for now, provide a help prompt for the user if they indicate 2 or more actions.
SystemFinal Design
I proceeded to make the prioritised changes to the design has ighlighted during usability testing.
This is the current implementation of the design where users can:
a recipe
Reflection
The Pancake Plaisir Journey
This is just the beginning, we can enhance the experience by making it multimodal.
I set out to design a recipe skill that would help people to find recipes, get inspiration and learn about new pancakes. I believe the current version makes a good attempt at this, however it lacks a vital component that comes with food for a lot of people - we eat with our eyes.
Taking a multimodal approach means that the voice experience can be enhanced as it opens up the Pancake Plaisir experience to more people where they can choose their mode and channel of interaction that suits them.
What Next?
Testing the recipe steps to check cognitive load and flow.
I am confident that users can successfully select a recipe, but the recipes I have are untested in terms of the steps the users take to make the recipe. Myself being an amateur pâtissiere, I am familiar with recipe steps - especially those that are complex and designed for reading. Thus I would need to test the recipe steps to check the amount of information presented.
The Challenges
Public confidence in conversation systems presents a large challenge.
Creating a conversation that is easy for them to take part in requires careful consideration of language and cognitive load. Here I used my linguistic background to aid me. However it’s a difficult balancing act for not overpromising on the system capabilities and not restricting users to a rigid conversation.
I am grateful for my conversation design mentor Darshana who joined me on this journey to check my thinking, providing me with opportunities for deeper learning. This has left me with more thirst for being part of projects that use voice intentionally
Thank you for reading the case study for