The Mjam Assistant —a customized selection view of your favorite restaurants in food delivery app

(Berlin, 2018–2019)
All existing food delivery platforms offer a kind of restaurant discovery, customized to customers' preferences. It can be for a specific time of the day, for example, lunchtime, so users can browse through affordable lunch offers from restaurants nearby. On other occasions, they can choose from a list of their recent orders, a favorite pizza from well know pizzeria. Or from a list of restaurants that don’t charge delivery fees.
Rarely do apps use complex algorithms to “remember” users’ preferences and display offers tailored to their taste and previous search.

When thinking of a typical situation when a person or a group choose to order food online, the usual ordering scenario would probably be somewhat like this:

A: Hey I am hungry.

B: Me too.

A: What do you feel like?

B: Pasta, you?

A: Pasta is ok, maybe pizza too, but please something fast.

B: Ok, but I don’t want anything shitty.

A: Well, how much money do we have?

B: It is ok, I have PayPal, and we can treat ourselves.

A: Ok. I can pick something on my way to work.

B: No problem, I will order …. Yay, our food is at the door in 20!

But … it’s not always as easy as it looks…

The Challenge & Discovery

In several usability tests, we conducted with end-users of the Austrian food delivery platform, Mjam (in Vienna, 2017–2019), and from quantitative research, we observed repetitive usability issues and some troubling behaviors, when it came to the restaurant discovery phase, especially with new users.

Let’s have a look at some repetitive insights from the data we gathered:

1. Users spend too much time ordering their food. Browsing the restaurant list, going back and forth to the menu page, took them in average 10 min
2. They often complained about seeing too many restaurants not relevant to them.
3. On average 32% of app users who convert see 9 restaurants before making a decision
4. Only 8,22% of app users use filters to narrow down the selection, but from those who use them, 89% select the restaurant from the results.
5. Only 12% of app users use sorting, but from those who use it 89% select the restaurant from the results
6. 52% trust the restaurants offered when filtered by super cuisine

The conclusion was when users choose to order the food they often find it very hard to find and choose the restaurant they like from the restaurant listing. They spend a lot of time browsing through the list and checking the menu offers on the menu page, repeating the process multiple times.

But from a few of those who choose to use the functionalities such as filters and sorting, the majority at the end selected the restaurant to order from, from the suggested list.

Defining pain points

There were 3 main pain points users had within the discovery process we could identify:

1. There are too many restaurants on the list, most of them not tailored to customers preferences
2. It takes too much time to find the right restaurant on the list
3. There is no helpful way to discover restaurants similar to what they like

Hypothesis

After the conclusion we believed we had a solution in our UX sleeve we wanted to test:

We assumed:

• If we present filters and available cuisines in a more prominent and more beneficial way, more of the new users, especially new, will find the food they like easier and faster
• If customers are able to save their preferences so they can easily find restaurants matching their preferences next time, retention & reorder rate could increase
• If a limited number of restaurants based on their preferences is presented to the users, time to order will decrease and CVR will increase
• The number of restaurants compared in the discovery process will decrease when presenting a limited number of restaurants based on user’s preferences
• A number of new restaurants will be discovered in a curated list of restaurants, based on given preferences
• USP → we will be able to convert more new users with the new flow because the food discovery is faster and better than with the competition.

Ideation and validation 0.1 — Chatbot

As a result of the first ideation on finding the right solutions, we were experimenting with the adoption of a chatbot pattern. We thought it could bring the value of a friendly and interactive experience to get valuable information about users’ preferences when picking the right restaurant. The collected information would be used to generate a curated list of restaurants at the end of the flow.

The solution was tested on a group of Mjam new and recurring users in a usability test in Vienna. If the concept would get positive feedback, the plan was first to create an onboarding version for new users as MVP as a next step.

The main goal of the research was to gather feedback from users after they interact with the chatbot prototype and to understand if the idea of narrowing down the selection of restaurants after the user preferences were provided provides value to them.

While interacting with the prototype, they were asked questions regarding their food preferences, and based on their answers they were provided a narrow selection of the restaurants as a result at the end.

Conclusion

Although all of the users really liked the concept and friendly chatbot experience, the length of the process was an issue for all of them.

We immediately responded and presented an iteration of the concept to the second group of users the next day. A friendly but lengthy chatbot concept was replaced with a so-called vending machine concept: all of the preferences were accessible on one screen without any additional steps needed.

Users' reactions to the updated version were positive. They responded the interface was intuitive, especially due to the simple interface and included visual elements.

Although the reaction to the new onboarding experience was overall positive, most of the users’ were less enthusiastic about the types of food preferences they had to choose from. Some of them felt there was not enough variety, the others just felt they are not relevant to them.

User research 0.2 — Food preferences

As a next step taken, we needed to redefine the types of food preferences that bring users the most value after being chosen.

In the current app, the filtering option was limited. Users could filter by type of cuisine, delivery cost, minimum order value — there was not much opportunity for curating the selection of restaurants.

It was important to learn what are the most important choices users think about when they are ordering food.

We already knew the most common, high-level food preferences when choosing the right food were:

Cuisine & Food type (& Dish)

Estimated delivery time

Food Quality

Price

Payment options

Delivery options

Since many users expressed they’d like to see more variety in that list, we added a few more such as food type, menu category, ingredients, taste, and preparation style and conducted a card sorting session.

From the existing data we had, we could easily add the most popular cuisines and top-selling dishes to a new individual group — Food Type group.

The rest of the groups were a combination of data from restaurants’ menus and competitor’s menus analysis.

The goal was to learn what comes first to users’ minds when they start the discovery process when ordering food.
Understanding which category of the preferences provided is most important to them would help us build a more accurate step-by-step curating process and better selection results.

The results showed most of the users would take this path below to narrow down their restaurant selection (1-most important, 8-least important):

1 — Cuisine

2 — Food Type

3— Menu category

4 — Time / Budget

5 — Menu category

6 — Ingredients

7 — Taste

8 — Preparation style

We had enough information to proceed to the next step — a decision tree.

Ideation — Bubble tree

I believe some of the readers of this article might remember Apple’s Music onboarding. Do you remember that red and black bubble interface which enabled the user to enter their music preferences and save them?

As user was selecting their favorite genre and producers, they’d see more and more detailed preference suggestions coming in. The suggestions got more and more specific towards the end so that the final results were a very precise list of suggested artists and albums, tailored to users’ tastes.

Yes, you’re right … That was another existing pattern we wanted to recycle and test with our users.

Apple Music app

As a first step, we created a decision tree, based on the results of the card sorting session, as a foundation of the new user flow.

The user would need to choose the type of cuisine first, which will trigger and display matching suggestions for the dietary choice as a next step, which would then reveal matching occasions and taste suggestions, followed and finished by the meal types…. We named the new feature Mjam Assistant. ❤

First prototype with a new decision tree as a foundation for the user flow

I know it sounds a bit complicated. We were worried too. :)

The challenge

Besides. as estimated, very complex development of the proposed feature, another essential component was missing — proper dish tagging (eg. the dish on a restaurant menu is spicy and vegan), which, unfortunately, didn’t exist on our platform at the time. Due to the constraints, we learned about we needed to abort the Bubble UX initiative :)

Moving forward — Mjam Assistant MVP

Nevertheless, unfavorable constraints didn’t prevent us from proceeding with iteration on the initiative and planning a new MVP version for the Assistant.

As we wanted to test the feature as soon as possible with less possible effort, we decided we will build Assitant with a simplified version of the preference flow.

We provided a limited choice of preferences, created by the existing filters, with an additional Save Filters functionality in a new Onboarding user flow.
We’d introduced the new MVP only to users who use Mjam app for the first time.
After they complete the Onboarding flow, the preferences they’ve selected would be saved on Meins (My Mjam) page with a list of restaurants filtered out in the onboarding flow.

The plan was to measure the number of users using the new functionality and the number of users selecting the restaurants from a new Meins page after they come back the next time.

User flow and UI design

When users first open the Mjam app and enter their delivery address, they would trigger the Assistant.
Within the next 3 simple onboarding steps, they were asked to select their preferred cuisines and narrow down the selection by applying a few more filters in the next step.

Mjam Assistant MVP

All selected preferences were then saved in a new app section called Meins (My Mjam). As a result of saving their preferences, they could now see the top 10 matching restaurants on the list. They could always refine their saved preferences by easy access to the Assistant feature from that page.

Meins Section

After the launch of MVP we were super excited by the execution of the experiment and we started collecting the eagerly awaited data.

Unfortunately, the first GA numbers were not as encouraging as anticipated.

Although the experiment showed positive results across the whole funnel (users visiting a menu page improved by 2.83%, Users adding something to their cart improved by 3.5%, users placing an order improved by 3.6%), ~70% of customers didn’t complete the assistant first step.

There was a bit more encouraging data from analyzing those users who completed the Assistant flow. They seem to be more committed to placing an order and:

• 93% visit a menu (vs 70% on average)
• 86% add the item to the cart (vs 60% on average)
• 83% go to checkout (vs 75% on average)

There seemed to be an improvement in engagement as expected:

• 95% of users who used the assistant come back to it at least once again.
• 60% of those customers place an order (vs 35% on normal listing page)

Since the results were more positive for the users who actually used the feature we decided to take a few more steps towards improving the Assistant experience:

• Run user interviews to get more qualitative input
• Promote Assistant to increase the discovery
• Once the food labeling project is established; update the assistant to include extra information: allergies, spicy, vegetarian, vegan…etc.

Final step — Usability test on the live feature

As one of the most concerning insights from the qualitative data was ~70% of customers didn’t complete the assistant first step, we wanted to understand why?

In the following remote usability test with Mjam users we were focused on a few main topics below:

• Why do most of the users skip the Assistant onboarding?
• How they perceive saved filters? Do they notice this is related to the choice they made in Assistant?
• Are the results of onboarding expected and relevant?
• Meins: why more users don’t interact with the feature in Meins?
• How can we increase engagement?
• Where would they look for the Assistant in the app?
• Why more users don’t save their preferences?

The top insight we gathered from the research were:

1. All users are aware of Assistant but no one is using it actively
2. They are not using Assistant because they don’t see a real benefit from it since it’s using the same filters as the ones available already available on the restaurant listing page
3. They would consider using assistant if filter selection would be based on more detailed/refined preferences such as dish level selection, dietary preferences, recommendations/popularity, new/upcoming, etc.
4. No bigger issues with UI design

Conclusion

Mjam Assistant as an MVP gave us a lot of insight and direction for the future development of the feature. It was clear that the feature would have a great value to all types of users if we provide a more refined set of preferences they could select from. The feature would be beneficial for the new users to help them discover restaurants they like faster, as well as for returning users to always return to their saved list of preferred types of restaurants.

But …. Unfortunately, before we could take any further steps to improve and complete the feature, some higher business decisions took place, and Mjam delivery platform couldn’t exist anymore after 2020.
Therefore a fully developed Mjam Assistant never saw a day of light. :(

Nevertheless, Mjam Assistant stays as one of my favorite UX projects I was working on with my team.

We achieved all of this together with the Mjam Product team, so thank you: Hesham, Antonia, Ola, Christian, and of course the amazing Mjam Tech team.