Savr Recipes is a voice enabled mobile application that provides home cooks with a hands-free cooking experience.
My Role
Solo project lead (UX designer and UI designer), while receiving guidance and support from my mentor, Laura
Methodology & deliverables
Timeline
​
1 week ( Sep 2022)
Tools​
Figma , Calendly and Zoom
Google Ventures Sprint Workflow
This project was conceived as a one-person modified Google Ventures (GV) sprint to be conducted in 5 days.
-
Proto personas
-
How Might we statements
-
Lightning demos and competitor analysis
-
Sketching
-
User map
-
Crazy 8
-
Story-boarding
-
Hi-fidelity designs ​
-
Prototyping
-
Usability testing
The problem prompt
Savr recipes is a fictional startup that wants to make it easier for people to cook great meals at home. Savr has received negative reviews about the length and advanced techniques involved in some of their recipes. They want to create a better cooking experience for their users. They also want to help their users follow the cooking instructions accurately and easily.
Constraints
-
Currently the recipes are written as text, in ordered steps from start to finish.
-
Need to be designed as a native mobile app.
Problem prompt, constraints, research highlights,1 user interview, and persona information provided by BiteSize UX on behalf of Springboard.
Solution
Savr Recipes is a mobile application that breaks down the cooking process into bite-sized chunks and provides users with a voice enabled hands-free cooking experience.
Gather tools and ingredients
Before starting the cook, the user gathers tools and ingredients required during the cook.
Voice mode
Users don't have to touch the phone during the cook and can use voice commands to navigate the app.
Cooking made easy
DAY 1: Mapping and understanding the problem
I spent day 1 of the sprint by reviewing and making sense of the interviews and persona information provided in the design prompt.
Meet Nick, the Persona
I categorized challenges based on when Nick and other users (from the research provided) faced them during the process to help me understand which part of the cooking process I needed to concentrate on.
​
Based on these inputs I came up with the following How might we statements.
Next, I mapped out an end-to end solution to the problem.
End to end solution sketch
DAY 2: Sketching
Lightning demos : Studying 4 mobile applications
I started day 2 of the sprint studying 4 mobile applications to understand how main functionalities that I was looking to incorporate in my app were tackled. I chose to study Tasty, Voicipe, Food Network Kitchen and Kitchen stories.
One challenge I faced was that I couldn’t find many examples of voice-based recipe applications.
Comparing competitor apps
Crazy 8 sketches - Focus on 'Start cooking' phase
Next, I used the Crazy 8 method to illustrate 8 versions of the critical screen in 8 minutes. Based on the pain points of the main persona Nick, I decided to focus on the ‘Start cooking’ part of the process. This was an exciting and difficult exercise to come up with drastically different ideas under time constraints.
Crazy 8 sketches for Savr Recipes
More definition to the solution : 3 panel sketches
Next, I created 3 sketches to represent the critical screen and the screens flanking the critical screen. My biggest challenge at this point was to figure out how to capture the ‘voice’ aspect in the screens.
The 3 critical screens - Finding recipe, recipe screen and recipe playing screen.
DAY 3: Decide
The next step was to define the solution further and create a storyboard that illustrated the solution. I debated dropping the voice aspect from the solution as I didn’t know how to execute it. After consulting with my mentors, I decided to feature voice mode as it solved one of the biggest pain-points of the user.
Decision : How much 'voice' interaction?
​
There could be several layers to the voice aspect.
​
-
2-way communication
The app could ‘talk’ to the user by reading out recipes and providing instructions; the user could ‘talk’ to the app by giving out voice commands.
​
-
1-way communication
The app would not ‘talk’ to the user, but the user would be able to give commands to the application.
Though having 2-way communication for voice seemed like a useful option, I decided against it as the pain-point of users having to touch screens during cooking can be addressed using voice commands and 1-way communication. There was also another consideration of whether I should provide the user with a recommended prompt or let user decide the prompt they wanted to use to get a job done. After much contemplation, I decided to only enable voice commands and not give the user the ability to structure their own commands to reduce complexity.
With increased clarity on the scope of the application, I sketched out the storyboard.
Lucy's journey : Storyboard
DAY 4&5: Prototyping
This step was the most challenging to me. I time-boxed tasks to help me finish prototyping during this day.
Decision : Voice mode in Landscape and video full screen?
Landscape mode would give prominence to the video/visuals in voice mode. However, I did not know how to translate that into a prototype. Hence, I decided to stick to the portrait mode.
Challenges faced
-
Getting the entire prototype ready in a day was a challenge. I had to complete the work over 2 days due to some interactions not working correctly at the end of day 4.
​
-
Accommodating many elements in a small space of a mobile layout and maintaining consistency across screens was challenging.
-
Effectively depict Voice mode features without confusing the users was a challenge as I didn’t have many examples to base my screens on.
DAY 6 & 7 : Testing
The next step was to test the prototype on users. I had reached out to potential participants on day 1 of the sprint and had a few confirmed interviews.
I did not specifically give sub-tasks as I wanted to see what path users would take. For e.g. before cooking, according to the current flow, users gather tools and ingredients. I did not specifically tell them to first gather tools and ingredients and start cooking as I wanted to see what users would do naturally without my prompts. I conducted 3 tests on one day and 2 others on the next day as there were a few no-shows.
Changes in navigation, status indicator and voice commands as pop-ups
Changes to timers, bigger pictures and text
Recipe picture added to voice mode
Conclusion
Savr Recipes was a wonderful learning opportunity and came with it some unique challenges, most of which were time-related.
-
I wish I had more time to explore prototyping with other software ( Voice flow/ Adobe XD), landscape mode and voice prototyping. The pace was so rapid that at times I felt overwhelmed. I learnt how to come up with scrappy solutions under time constraints.
​
Impact metrics
If Savr were a real-world application, I would consider the following metrics to measure the efficacy of the application
-
Session length and depth ( indicating that the user was using the app to refer recipes and cooks with it).
-
Daily / Monthly active users.
Retrospective
-
I learnt later that asking the user to use specific voice commands was not intuitive and natural way a user would communicate with a voice app.
​
-
I took an extra day to prototype and another extra day to conduct my interviews. I didn't use Day 3 effectively and should have started prototyping on day 3 to save time. This project illustrated to me the importance of time-boxing.
​
-
I had a ‘no-show’ in my usability test, because of which I had to continue my testing on another day. Next time I would line up some back-up usability test participants so that not having participants would not be a bottle-neck in the design process.
Want to see my other projects?
