Have you ever had trouble cooking while following a recipe on your phone because your hands were busy or dirty? I have. That's why we created Gusto, a cooking assistant that helps users find top-notch meals and guides them by voice during the realization.
Product Designer
Team of 5 with Product Manager, CMO and 2 developers
Benchmark
User interviews
Surveys
App design
Facilitation
VUI Design
User tests
UX Analytics
Adobe Xd
Fabble
Whimsical
Firebase
4 months
The Double Diamond is a framework popularized by the British Design Council that stimulates innovation and gives a clear methodologic frame. It is composed of 4 phases:
Discover : understanding users, their problems, their needs, as well as investigating on the causes of the problem to solve and the opportunities it involves. It is a diverging phase, where a lot of data is collected through research.
Define : narrowing the problem to solve by defining a clear and concrete challenge. Insights gathered earlier are synthetized in this converging phase.
Develop : searching answers and solutions to solve the problem defined. It includes a diverging ideation and a prioritization of the ideas generated.
Deliver : prototyping and testing solutions defined earlier. It is a cyclic diverging phase, animated by several iterations to improve the prototype each time.
To build a relevant cooking app, we had to gather information about users but also about the market, which is quite tense, with a lot of competitors. What is the role of technology in our users' kitchen? What do they expect from a cooking service? Are they willing to use a vocal interface? What do they think of current services?
To overview users' habits, we collected both qualitative and quantitative data: we built an online survey and conducted 6 interviews with different archetypes of users. Here are the main take-aways:
80% of respondents cook at least twice a week, but sometimes lack of time or motivation
Cooking is seen as a pleasing activity, which is funnier when shared
90% of respondents use recipes regularly, that come from social networks or websites
30% of respondents use a vocal interface on a daily basis, via smartphones or vocal assistants
Once we knew more about users, we had to explore the market, in order to identify strengths and weaknesses in the offer. We focused on the cooking app market, but also on the vocal, because we felt an opportunity laid there.
Famous websites (around 8 millions visitors a month)
Trusted by users
Community-oriented: everyone can post a recipe
Skills on Alexa and Google Assistant
Pictures and videos at the core of the experience
Lot of tags to push relevant recipes
Good communication on social networks
Vocal commands to navigate between recipe steps
Focused on a particular type of recipe
Became references in their own markets
Hard to compete with them
No vocal
This phase is based on convergence of informations. Once we knew more about our potential users, we had to map their objectives and needs in terms of cooking service. The we have expressed those in the form of Jobs To Be Done, that could leverage ideas generation in the next phase.
Then, we mapped for both personae that moment where they make the decision to cook. The idea was to clarify the experience components to understand users at a deeper level and address their needs with our product.
Finally, we built those JTBD to sum up the Discovery phase with actionable and precise statements, on which we could rely for the Ideation:
When I don’t have time, I want to prepare a meal quickly, so I can enjoy my evening with my friends.
When I feel lost, I want to be helped step by step, so I can cook delicious meals.
When I cook, I want to access nutritional information, so I can watch my diet.
When I search for a recipe, I want to find new ideas, so I can surprise my family.
When I decide what to cook, I want to access high-quality recipes, so I can use my cooking skills.
When I cook, I want to gain some time, so I can enjoy the day with my kids.
It was time to let creativity explode. Based on the Discovery, we had to build a new way to answer users needs. We first led a brainwriting to consider all possible solutions, followed by an Impact/Effort matrix to organize and prioritize them. Finally, we made a focus on Gusto personality, both as a brand and as a vocal assistant.
I organized an ideation workshop with the whole team, which started by a brainwriting exercise: we had 1 minute to find ideas individually for the first JTBD, followed by a 5 minutes discussion. This process was repeated for each JTBD listed to obtain this list of ideas:
The second exercise of the workshop was an Impact/Effort Matrix. It is used to prioritize the most impactful ideas for users compared to the effort they require to be developed. It allowed us to have a solidified vision of our product with a list of what should be its main features.
This workshop led us to the creation of a vocal assistant, that could help our users find and realize top-notch recipes, based on their cooking skills, diet and favorite ingredients. The last exercise of the Develop phase was to give this assistant a name and a personality. We wanted him to be as professional and efficient as Alfred from Batman but also as friendly and helpful as Auguste Gusteau, from the Disney movie Ratatouille.
Our head full of ideas, we needed to shape Gusto as product. With this objective in mind, we led several iterations and tests that allowed us to design both an app and a Vocal User Interface (VUI) and to define an evaluation process for them through the HEART Framework.
First, we determined the app architecture, gathering and organizing the most important features for our users with a guarantee of coherence and browsing fluidity. This sitemap has been modified several times following our tests, here is the latest version:
Then, we built wireframes to illustrate the navigation defined by the site map and evaluate information hierarchy on each page. The objective was to display content and quickly test our first draft, without a deep graphic work and the aesthetic biais that comes with it.
Onboarding
Recipe - Ingredients
Recipe - Instructions
Fridge
Vocal
We led two different types of tests:
- 10 unmoderated tests with a list of tasks to complete and a survey to give feedbacks
- 5 remote moderated tests with the same list of tasks and live feedbacks on their feelings and thoughts.
Here are the main insights we collected after an Affinity Map analysis:
67% of users felt that Gusto should be more present in the app to become a real cooking assistant
The features clarity was rated 6.8/10 and users highlighted the benefits that could bring a tutorial on first opening
In users mind, the cart was too deeply linked with buying so we changed it into a shopping list
Then we built Gusto brand identity. Starting with colors, we wanted to express vitality and health so we chose high saturated green and orange as primary and secondary colors. They have been declined in dark and light shades to guarantee the accessibility of our product.
#0e781b
#ff6021
#002404
#f7f5eb
#FFFFFF
Concerning typography, we headed towards a rounded but easily readable font: Nunito. Being a mobile-first product, our styles could not be so different one from another to keep balance and remain responsive.
Text - Nunito Regular - 18px
Subtitle 1 - Nunito Semibold - 16px
Subtitle 2 - Nunito Regular - 16px
The logo had to be friendly and distinctive, that's why we used a chef illustration above a logotype, with rounded lines and a flat design. This illustration will be our app logo to center the communication around the concept of personal chef.
Once Gusto brand identity was set, we built some components that would be used throughout the app. We designed different types of controls, cards and call-to-actions while maintaining a visual coherence between them, in order to offer a good scannability to our users.
With those, we finally built pages and interactions to get our first prototype. Its objective was to be a first representation of our product, that could be tested and improved. Here are some of the main features:
Tutorial
On first opening, Gusto directly speaks to the user and present the app main features, focusing on users benefits. Our first draft of tests highlighted the necessity of a tutorial and users that explore a product are more likely to use it regularly.
Home & Recipe
The homepage is a personalized recipe list, based on user's tastes and diet, with high quality pictures and main infos about each one. Once a recipe is clicked on, a card unfolds to present all required details to cook.
Fridge
Gusto allows users to find recipes based on ingredients they already have. All those ingredients can be found (via categories or search) and selected to access a dedicated list of recipes, with a compatibility percentage.
Shopping List
Finally, we identified groceries as one of our users' main pain points. Gusto simplifies this task by allowing users to directly select ingredients from a recipe and create a shopping list, which can be sent or exported.
This iteration ended with a testing phase again. Same as before, we combined 5 moderated and 10 unmoderated tests to gather feedbacks on Gusto prototype. Here are the main insights we analyzed, which will be used for the next iteration cycle:
81% of users don't use likes and comments to choose a recipe and trust Gusto to make good recommendations
Users who forgot an ingredient in their shopping list would use a search feature to find it and add it
34% of users showed difficulties to use the vocal feature because they were not used to it
To determine the vocal service provider we would choose for both Automated Speech Recognition (ASR) and Natural Language Understanding (NLU), we did a benchmark. We wanted to evaluate the performance as well as the pricing, based on an average 31 vocal requests per session.
Google and Amazon offer the same pricing structure, a fixed price for each request, hosting included. We preferred to go with Nuance, which bills a fixed price per user per year, which was more advantageous for quite similar performances.
Every Vocal User Interface (VUI) has its own. It is used to indicate that a request is about to be formulated. Some sounds, such as [ke], [gue], [o], [inne] and [ta.o] are quite distinctive in French, which makes them more easily recognizable for an ASR. We also wanted to avoid an hollow word such as "OK" or "Hey" because it could impact the naturalness of the conversation.
That is why we simply chose "Gusto" as our wake-up word. It clearly indicates a will to chat and it can be repeated several times in a conversation without being annoying. We also set up a listening delay after a request during which the user doesn't have to start by saying "Gusto".
VUI Design has its own vocabulary. Basically, to prototype a conversation, one needs to define "intents" which is what the user is trying to accomplish, "uterrances" which are the different ways a user will formulate an intent, and "slots" which are the variables used to specify intents.
For example :
For the utterance : "I would like a large pepperoni pizza"
The intent is : [order_pizza]
The slot {size} takes the value "large" and the slot {pizza-type} takes the value "pepperoni pizza"
Concerning Gusto, intents could be [find_recipe], [start_recipe], [list_ingredients] or navigation-related such as [next_step], [repeat] or [go_back]. Next task was to list as many utterances as possible for each intent, based on user interviews and shadowing. For the slots, most of them were recipe-related: {ingredient}, {prep-time}, {number-of-people}, {quantity} etc.
I prototyped Gusto VUI on Fabble.io, a voice design tool that doesn't require coding skills. For several recipes, I built conversation trees, defining all the paths users could take depending on their intent. Both users requests and Gusto answers had to be listed and organized. Unfortunately, Fabble doesn't allow embed prototypes, but the opposite snapshot shows an example of a conversation tree I built.
Gusto is now ready to go live! To monitor its launch and analyze its performance, we have used the HEART framework, developped by Google, to identify KPIs that could help measure the user experience. Those KPIs will be tracked on Firebase.
Number of support contacts
Comments on app stores
Number of app sharing
Number of recipes consulted per session
% of sessions starting with a notification
Social media interactions
Number of app downloads
Ratio downloads/deletion
% of use for each feature
Number of recipes realized through time
App opening frequency
Number of inactive users
Exit rate for each feature
% of recipes realized via vocal
Number of vocal requests for each session
Building Gusto helped me develop my VUI Design skills with a deep dive into vocal mechanisms, technologies and problematics. I have been able to imagine what speaking to Gusto would feel like, structure the conversation, detail its components and prototype it. I also improved my knowledge of vocal tech and the different programs it requires.
I also learned how to create an avatar for a product, which should represent the brand and be aligned with the service proposed. It was an interesting brand design challenge, which combined illustration, naming, color management and tone of voice.
Most of the difficulties I encountered were caused by the software stack I chose.
Adobe Xd felt a bit limited in terms of interactions and scalability. I would have feel more comfortable with Figma and the last Xd updates showed me that it was heading towards AR/VR instead of VUI.
Exploring VUI prototyping tools, I realised Fabble was not the best choice neither. I have had the opportunity to work with Voiceflow lately and I think it would have been better to use it with Gusto, regarding its conversation flows and its management of intents and utterances.