Wireframe, Landing Page, Validation

As part of our mission, we will take care about clients, waiters and restaurants owners needsRaising Hands
We designed two different experiences that will cover both customers and services providers scenarios.


Customers app

designed for mobile use Mobile Phone with Arrow
based on QR code that drives to landing page


Short description
Menu page → will display search option for items to be ordered
Product details page → will provide description of selected product
Order page → will provide cart with all selected items
Chart page → will provide all available options regarding client flow
User info page → will show the profile of current user, including card details if applicable
Previous orders page → will display a history of all orders within the restaurant
Bell The ringbell can be use to notify the waiter that a customer needs either help or assistance. In order to assure inclusivity and be aware of any customer problem that cannot be resolved through application.



Restaurant staff app

designed for tablet use
used by waiters and managers to monitor restaurant-wide activity



Short description
Landing page → displays an overview of the representation of tables and their status. The waiter or the manager can search through the tables by reservation name or by id or simply click on the desired table to get more information.
Table page → will display the status of a table: whether it is assigned to a waiter, the order and the status of delivery for each item in the order
Assigned tables page → will display all tables and orders assigned to the waiter logged in the app
Statistics page → provides insights about restaurant's or waiters' work - 2 different pages for waiters and managers
Waiter → can see own statistics
Manager → can see each waiter's statistics, as well as restaurant-wide


Landing Page



User Persona





User Stories


As a client, I want to see the menu, so that I know what food choices I have.
As a client, I want to see what I ordered and how long it will take to be ready, so that I know what to expect from the service.
As a client, I want to be able to call my waiter directly to the table, so that I can solve issues outside of the app.

As a waiter, I want to see the tables I am assigned to, so that I have an overview of my work.
As a waiter, I want to see each table's order, so that I know what to bring there.
As a waiter, I want to check the orders as delivered, so both the client and I know its status.

As a manager, I want to see and update items in the menu, so that I can keep it interesting for the clients,.
As a manager, I want to see sales performance statistics, so I know how to improve sales' strategy.
As a manager, I want to see my employees' activity, so that I cam monitor them more closely.
As a manager, I want to see the most popular and unpopular orders, so that I know how the products are performing.
As a manager, I want to see the average bill, so that I know how much money the customers are usually spending in my restaurant.



Use Case Diagram




User Flow Diagrams













Bullseye Motivation for MVP aspects

Obs. The MVP is generic - we implemented an application that works from any restaurant or event venue.

Client functionality is separated from restaurant functionality
This choice was made to support the idea of linked menu. We want the customer to be redirected to a page that contains menu and ordering functionalities. The page is separated from our main application - meaning that, the ordering process works for any user that access reserveit/tables URL.

Customers can:
select items to order from certain categories
This is the basic functionality that we achieved. For the internal management to work, this functionality allows us to gather all orders in a database and communicate the information into the staff side application.
notify the waiter to come to the table
As we know that technology can improve, but not replace all types of human interaction, it is important that we implemented a functionality for notifying the staff to come check any uncovered situation from a certain table.
request the bill
Another automatic process from our application is requesting the bill. This is a key is in saving time for a restaurant customer, and comes in hand with the improved ordering process.

Restaurant owners can:
add specific products to a category, and configure the menu that the customer sees
For the generic application to run, it is important to allow our clients (mainly restaurants or event managers) to customize their menu.
configure and visualize a map for restaurant tables
An overview of all tables is required when the manager wants to quickly get an idea about orders statuses or change the venue arrangement.
see all orders and their statuses
The same functionalities available for staff should be consistent for the admin. The restaurant manager should visualize and correct the order statuses, as there can be situations when a third-eye is needed to handle problematic orders.

Staff can:
see all orders and change their statuses
For waiters to handle their workload, a list with all pending orders should be available to them. Organizing the orders by their statuses and updating is a main response functionality, that allows end-to-end communication to restaurant customers.
see notifications from customers
Another list of notifications (bill requests or simple notifications) should be visible from a waiter's point of view. The waiter can close a notification after it is handled.




Money Bag First sale

Our first sale turned out to be very successful, there was a wide variety of users interested in out product.
As expected, some of the users, that were not interested or curious of the problem that our app solves, left after the landing page. Due to the fact that it is a MVP, the landing page of the app does not have all the requirements that help with the retention of the users:
it has no explanation about what the application can be used for
it has no images to describe the area of usage
has no reviews or verified labels

The statistics and the feedback we received from the users we shared the app with shared great interest in the restaurant side. The statistics show that they spent most of their time in the customization of their own restaurant, they created their own menu and their own table placement. This validates the fact that our target user is an event organizer, that permanently needs to change the location and the menu. In the MVP the UI is simple and intuitive, they seemed to understand pretty well how they can use the app for their business.

Because of the fact that this is our first sale, we did not create QR codes for the tables of the restaurants. It would have been more difficult in the engagement testing side, thus we opted for sending URLs for the domain where they can test the features that a client can have when using the app of a restaurant. The audience shared a great feedback again regarding the ease of using the order menu, it is developed in a similar way to the one most of the ordering apps have, thus it is familiar for users. They also tested the end-to-end flow of communicating with the waiter, some of the interested users, entered on the restaurant app after placing an order.

From the statistics we can observe that the restaurant app is more suitable for a desktop use. The ordering app showed similar usage in both devices.

Most of our users are in Bucharest and this is a great asset to our business due to the fact that Bucharest is known for the high demand in the event area.