Enabling restaurants to process online orders quickly and conveniently
PRODUCT DESIGN
Disclaimer: The views and opinions expressed in this study are those of the authors and do not necessarily reflect the views of the organisation or its members.
Local office park restaurants often attract a loyal customer base from the nearby offices because of location. These restaurants often remain quiet for most of the day, but require a fast paced system for the rush hours. Customers end up wasting time waiting for food while the restaurant struggles to speed up in those limited hours and then sits idle.
Visitors return for the food but they spend majority of their lunch hour waiting to place their order, make the payment and preparation of the food. This is wasted time which could be better spent eating their meal and actually getting a break.
Problem
There are many amazing local restaurants within office parks where the food is of high quality and conveniently placed . They often attract a loyal customer base from the nearby offices and once the word spreads, they start to see a lot of regulars during lunch time. These restaurants often remain quiet for most of the day, but require a fast paced system for the rush hours. Customers end up wasting time waiting for food while the restaurant struggles to speed up in those limited hours and then sits idle.
Visitors enjoy the food but they spend majority of their lunch hour waiting to place their order, making a payment and waiting for the food to arrive. This is wasted time that could be avoided if these customers had access to the menu to decide on what they wanted to eat, place their order and pay online. This way their lunch time would be better spent eating their meal and actually getting a break before getting back to work.
My Role
I was one of the 3 co-founders of Menu Ninja. With the other 2 team members being software engineers, we were building faster then we could learn. This meant that we had an MVP before we had a concrete team going. While this was a great starting point to learn from, the UX processes were haphazard and provided value in iterations. Changes were made quickly in tiny, impactful tweaks where we saw that it was valuable.
I spearheaded the product design. This included the following:
- Leading and facilitating product strategy sessions & learning through webinars / experts
- Learning from the usage of our MVP & executing on changes
- Leading customer research
- Building wireframes, design artefacts and flows
- Designing the UI and interactions
Solution
The solution was a simple online platform where these small restaurants could quickly and effortlessly upload their menu items. The core value being that they could share this link with their existing customer base. These customers could then place their orders and make payment for their food online to avoid wasting time and energy during lunch time.
A CMS for managing the menu and online business, a kitchen app for accepting and tracking orders, an online menu for customers to place orders.
Take a look at one of our live restaurants using the web app: https://www.themenu.ninja/roots
Approach
Small owner-run restaurants are a common occurrence in our neighbourhoods.Specifically office parks tend to have a limited amount of footfall, and so you would often find that there is only 1 restaurant with limited staff that serves all the offices close by. These restaurants are risky to run as they rely on repeat customers and catering orders.
Knowing that breakfast and lunch hour will be busy, these restaurants can maximise on the quieter hours by accepting customer orders online. The restaurant can prepare the orders before the rush and customers don’t have to go through the ordering and paying process manually and in-person. More importantly, everyone in the process can spend their time more effectively, because the ordering process is completed asynchronously. This contributes to flexibility and convenience for both parties, especially in terms of time.
The team involved in this project had full time jobs while we built this, and therefore we needed to use our time, money and resources carefully. We followed a bootstrapped lean startup approach. This meant that we needed to learn as we built, and we used those learnings to iterate on the MVP.
Develop the MVP
Build
Instead of using a theoretical business model to get feedback from customers, we decided to build a working prototype for a restaurant and learn from it.
Measure
We wanted to ensure that we had a baseline to measure usage, flows and changes.We built integrations into web optimization tools for this.
Learn
Restaurant qualitiative feedback was used for validating the solution. We ran discovery sessions with restaurants to gain insights and understand pain points.
Iteration 0
The MVP was a success and within weeks the restaurant was asking to edit the menu and wanting to update recurring specials. This led to integrating a lightweight CMS and customising the architecture via Docker to make it multi-tenant. We were moving really fast and only verbal design feedback was given at this point. The purpose of this iteration was to validate problem-solution fit.
Build
The MVP was a lightweight solution with a view for customers, a view for the kitchen to manage the ordering process and a CMS to manage the menu items.
Measure
We knew we had a possible problem-solution fit when the restaurant owner started advertising the online menu and started receiving orders online.
Learn
The optimization tools provided insights about browsers and devices our customers were using, friction points and technical issues
When a business uses your product, they are putting their faith in you. The product acts as an extension of their identity to the customer. Having the Menu Ninja link on the restaurants social media and mailing list gave us the confidence that the restaurant was seeing value in using this product and was willing to put it in front of their customers.
Iteration 1
Build
We knew that we needed to build a solution that solved a problem for at least one business, but that it would need to scale for us to be profitable. We made the following assumptions to constrain the solution:
- Majority of visits would come from existing customers of the restaurant
- Product value is based on improved internal processes for the restaurant - NOT as a marketing tool for new customers
- Improved internal processes would help restaurants create better customer experiences and attract more loyal customers
The journey map was a tool we used to create clarity on the specific points of friction that the solution would impact.
With limited resources, the wireframes were used as the design output during this iteration
Desk Research: Ordering from an online menu
Desk Research: Food cart and updating preferences
Desk Research: Building trust in the system
Design during this phase included journey mapping, desk research, wireframing and learning from the MVP usage.
The purpose of desk research was to understand best practices and industry standards for specific flows. Based on the desk research, analytics and user interactions on the platform we built wireframes to improve the current MVP. Changes to the app were based on the wireframes in this iteration - using best effort to update existing screens with changes in layout and de-prioritizing any big changes suggested by the wireframes.
Measure
Using web optimization tools to measure and learn about the sales funnel and drop off rates
Learn
Learning from customer usage of the interface to make improvements
Usage insights highlighted improvements to make:
- A snackbar when adding an item to the cart was distracting users. Users would click it when it came up, and by that time it would disappear. We replaced this with a floating button to take you to the cart.
- The specials were on a separate page. People would have to navigate away from the menu. We brought the specials into the menu as the first section so that there was a consolidated view of menu items and specials for customers to choose from.
- The online payment screen naturally had many drop-offs. We improved the form for standardised payment input field names and introduced subtle trust elements.
We confirmed problem-solution fit with this iteration as we saw repeat customers using the platform.
Iteration 2
Build
UI in Sketch
We decided to use material design as our base. All components were built using the mental model of atomic design.
Atomic design used to create styles, symbols and components in Sketch
Measure & Learn
Introducing design elements based on insights, to improve customer experience
Based on usage data we gained the following insights:
- There were customers wanting to pre-order food for the next morning so we introduced offline ordering
- Abandonment during checkout started to become apparent. We decided to apply the hueristic principles of visible system status and freedom and control to enable users to feel that they were not being tied into their decision. We did this by adding a stepper into the checkout flow to show progress and improved descriptions at each step
- During COVID Lockdown, Level 2 restaurants were able to open up with delivery only. We decided to introduce delivery features even though it was outside of our scope as it was relevant to restaurants processing orders during lockdown
Outcome
We are continuously learning and improving on the product.
We have seen promising results based on our first few customers. Repeating customers on the platform are starting to place larger orders and sales on the platform are increasing steadily.
The user flow for restaurants using the system to fulfil customer orders
Total Sales - slowly increasing (May - July)
Basket sizes of repeat orders are increasing and the restaurant is using the menu for additional income streams (eg. catering, frozen foods)
Learnings
1. Businesses at different levels of maturity require different mindsets. Working at larger businesses where product-market fit is relatively known allows for a stable ground to implement processes and long term strategies. Starting a business from the ground up requires a completely different mindset. We did not have the luxury of time or budget to implement perfect designs, feature rich solutions or in-depth research. We had to look at what was good enough and iterate on this. Now that we know we have solved one restaurants problem well enough, we can start looking at product market fit in order to scale.
2. Restaurant owners are always looking for ways to increase sales. When we met with these owners, the immediate response to our solution was to ask if we were able to provide a marketing twist on the solution. Often these business owners could gain more sales and repeat customers through improved processes but they become focused on attracting more new customers using existing processes instead of investing in tools to improve processes, that would result in improved customer experience and therefore increased sales. This was something we had to learn through our research. We had to ensure that we didn't immediately deviate from the problem area because of feedback at face value.
3. Introducing new systems to a very manual environment proved difficult. There was an additional cognitive load of introducing a tech solution to something that was done in a very manual and streamlined fashion (even if this meant that customers had to wait longer) through an individual channel. We tried multiple tactics to ensure that the solution was adopted by introducing sounds to the web app when an order came through, buying a dedicated device for orders and using SMS notifications. We learnt that the SMS worked best as it was the closest and most familiar form of communication that was already part of their work environment.
