COLAB11 - Mobile App

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:

  1. General menu layout
  2. Font and text size is too small/large
  3. Not all dishes have pictures 
  4. Dish customization potential (ex. can a dish be made vegan or not)
  5. Having to read an entire menu before you know what to order
  6. 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

Lofi
Hifi: Core Journey 
HiFi: Add-Ons
Augmented Reality #1
Augmented Reality #2

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.

Designer Learnings:

Jo Sturdivant

  1. Adapting to an Established Team: Joining the team in week 6 of 8 was challenging, as I had to quickly adapt to existing workflows, dynamics, and goals. This mirrors real-world situations where you often integrate into teams mid-project, and flexibility is essential.
  2. Work-Blocking for Efficiency: With only two weeks to complete the project, I learned the importance of a structured work-blocking system. This approach allowed me to manage my time effectively and meet deadlines under pressure.
  3. Making Data-Driven Design Decisions: Unlike my past projects, I had to rely on research conducted by others. This was a valuable experience in using pre-existing data to guide design decisions, helping me focus on the core insights without starting from scratch.

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.

Developer Learnings:

Vanady Beard

&

As the back-end developer, I learned how important it is to create efficient and reliable systems that support the entire application. This experience also taught me the importance of optimising the database and ensuring the backend is scalable and easy to maintain.

Developer Learnings:

Stephen Asiedu

&

As a back-end developer, I've come to understand the importance of being familiar with various database systems and modules. This knowledge enables me to build diverse applications and maintain versatility in my work. I've also learned that the responsibility for making the right choices rests on my shoulders, guided by my best judgement.

Developer 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.

Developer Learnings:

Maurquise Williams

&

  1. Process of Creating an MVP: Developing a Minimum Viable Product (MVP) taught me how to focus on delivering core functionalities balancing between essential features and avoiding scope creep.
  2. Collaboration in a Real-World Tech Setting: This experience taught me how to collaborate efficiently in a fast-paced tech environment, keeping the team aligned and productive, even while working remotely across time zones.
  3. Sharpening Critical Thinking and Problem-Solving Skills: This experience honed my ability to think critically and solve problems efficiently. By tackling challenges and finding quick solutions, I sharpened my decision-making and troubleshooting skills in a dynamic, real-world setting.

Developer Learnings:

Jeremiah Williams

&

All in all this experience was very awesome I learned that in coding with others being transparent is key

Developers Learnings:

Justin Farley

&

I learned how important communication is when working with a team. Communication provides understanding, advice, ideas, and much more. While working with the product team, I’ve found that communication keeps everything flowing smoothly. Working with a team also showed me that every member brings something different to the table and we all have to work together in order to align and meet our end goal.

Full Team Learning

Trust the process and trust each other. 
Thank you David.