momenu
QR code menus aren’t great- Momenu lets diners search, filter, favorite, and save any dietary preferences for next time.
Problem Background
During the Covid-19 pandemic, restaurant owners were forced to adapt to the changing standards of sanitization. As a result, one of the first changes made was to introduce QR code menus or QRMs to replace handheld ones. Since this was done so hastily, most user experiences with them leave a lot to be desired by the customer. The path to the meal that they will theoretically enjoy the most, or winmeal, is often ruined with either too much, not enough, or the wrong information laid out in an unfamiliar way.
When diners visit a restaurant for the first time, it’s important that they enjoy their meal since more than 87% of surveyed diners say that they wouldn’t return a second time if they didn’t enjoy their first visit. We have realized that the likelihood of a winmeal drastically improves if the customer not only has all of the information they need to make their decision of what they would like to order, but also is presented with that information in a clean and fast way.
User Pain Points + Feedback
When diners visit a restaurant for the first time, they experience a moment of uncertainty when they scan the QRM on the table. “Will this take me to a pdf?” “Are they going to immediately ask for me to sign up for a mailing list?” “How long will it take for me to figure out how to use it?”. These are all popular concerns that most of those surveyed had voiced. We decided to zoom in on a few that hit several nerves:
- General menu layout
- Font and text size is too small/large
- Not all dishes have pictures
- Dish customization potential (ex. can a dish be made vegan or not)
- Having to read an entire menu before you know what to order
- Lack of information regarding portion size
With this in mind, the team began user research and problem/solution discovery. We created a script that all team members used to collect data and feedback on some of our hypotheses. We made a specific note to not include any feature questions and ultimately decided to ask broad questions that would lead to more discussion.
The responses were noted from each participant and were color coded accordingly:
Themes and other appropriate groupings were noted and the responses began to provide valuable insights.
It was at this stage where we realized that having a two tiered approach to our product would make sense and that we should test that first. Since the market already has a viable solution for QRMs, we wanted to ensure that we provided that experience as a minimum as to not upset the user. If during a session a user wished to access additional “spicy” features, they could simply proceed. This then became the difference between our “core experience” and our “add-on” experience.
Before we began development of these core features right away, it was imperative the team was able to prioritize the tasks. We decided to give personal feedback on perceived risk, effort, and impact on our initial set of features.
Once this was completed, we plotted them into the feature priority matrix to determine where we should begin and how we should populate the backlog as well as our first sprint backlog.
Landing on the Solution
When using momenu, diners will experience a fuller ordering experience and expect more from the restaurants they visit. QRMs tend to vary widely which tends to lead to confusion, frustration, and an overall poor user experience. We think that diners will enjoy familiarity and will come back to restaurants again and again. Making our feature decisions with this in mind is our guiding light.
Explanation of the Solution
Offer users a basic post-scan journey coupled with an opt-in enhanced UX. First to provide a menu viewing experience that is a much cleaner and more intuitive version of the existing QRM: better layout, mobile optimized, responsive photo/descriptions, etc. The option to view the "personalized" menu is shown and the user has the choice to proceed or to remain on the "standard" experience.
Lofi & Hifi Mockups
Iterative Design Learnings
After we showcased our prototype to the users again, we learned that:
- icon heart instead of bookmark
- added a “more” link after last item in horizontal scroll (Today’s recommendations) and changed title to “Chef’s choice” as well as limited the number of shown dishes
- Feedback animation necessary when user tabs on heart “added to Favorites/ removed from Favorites”
- re-design search functionality:
- opening --> scroll down from top opens search bar active
- results --> don’t separate search results by category, show all, --> added “All” tab on the left as default
- increased size of magnifier icon
- added scroll past category jump to category (tab - starter - main - dessert). So all items in one list with changing fixed header
- removed the “save list” button from the open Favorite list, and replaced with “ready to order” to emphasize the missing cart & payment in the app and point users to call the server
Implementation Details
Where is it hosted?
- Mobile:
- Backend: Heroku - https://pikeey.herokuapp.com
What is your tech stack?
- Django (Python Backend)
- Swift (Mobile Language)
- UIKit (Mobile Framework)
High level journey of a request
- User/Client request scans a code -> a call is made with restaurantID to the database through the view using “https://pikeey.herokuapp.com/restaurant/<restaurantID>” -> If restaurant exists, details of the restaurant is returned back to the client as a Json and the client can render the data.
What was the hardest part of development?
- Building some features, and also having to leave out some amazing features.
- Displaying the meals group by section.
What are some key takeaways?
- The application was built separating the client side from the backend. This will make scaling easier and separate concerns. It will also make adding features easier.
- Also, making the server available for different clients is in the works.
Future Steps
The feedback we received during this entire process has been incredibly positive and the team shows interest in possibly continuing on after graduation.
Learnings
Product Manager Learnings:
John Marzo
It wasn’t a surprise that the curriculum was rich and that I improved very actionable skills for my career including user research and feature prioritization, but what was a shock was how much I would learn from my teammates. I truly am grateful to have met them.
Designer Learnings:
Tabea Lessing
The practical experience has been very valuable but the ability to communicate early on with the developers and distill down ideas into actual designs has been wonderful. The team grew so well together and we were able to trust one another to get the right things done.
Developer Learnings:
Jibola Bakare
I was looking forward to building good communication skills which will build my relationships across departments, but my experience was more than that. I was able to build an amazing product that users have been able to give positive feedback on.
On top of this, I have been able to build from the ground up; get feedback from user interviews; understand what makes a product; share ideas on what to build, how to build; give thoughts and feedback on design; iterate on user feedback and make estimates of features built and to be built.
I have also learnt that it is better to fail fast and forward by releasing an iterative product, where a usable product is released, and features can be iterated over as user feedback starts to roll in. Meaning, start small, from building the basic things your users need, then you can start to test features/ideas.
Developers Learnings:
Eric Morales
&
I was able to get a grasp of the different roles that the different team members had on an evolving basis. As a developer I understand the tasks and deliverables that are asked of me, but it was interesting to see what sort of additional steps are required to bring cool technology to life. I now know what to expect when I get into the workforce and how I fit into the overall organization and team.
Similarly, I got to develop my communication skills and how to use them when prioritizing different aspects of development in order to achieve our goals. I also had to work with teammates all around the world and it was a challenge at first, but we grew together as a team and figured out how to be in sync.
Full Team Learning
Trust the process and trust each other.
Thank you David.