beepDelivery Tablet App: Phone Order Redesign

💭 Background

Food delivery has been developing exponentially all over the world, including in Japan. The hectic, high mobility of its people keeps the demand strong for simplicity in everyday life. In addition to the pandemic era, people are even more cautious and tend to choose contactless purchases. The shifting in lifestyle creates an urgency for the food industry to start digitalizing their business as well.

beepDelivery is an emerging food delivery service that started off in Tokyo, Japan. Jumped into the bandwagon, it has released the first version of each of its platforms.

Learn more about the services here. In short, there are 4 kinds of services they are providing which are consisting of:

an order site for customers,
a management application for restaurant staff,
a management site for company & restaurant managers,
a delivery person application.

🔎 Understanding the Problem

beepDelivery has always been developed in a tight schedule to catch on the deadlines and demands. The platforms were created based on blue-sky concepts by product managers & developers with little consideration for both technical bugs and anticipation for users’ experience.

This was the initial design for the phone order:

When that design was released and tested in some partner stores, there are some complaints arising from restaurant staff in the phone order flow. We created a persona to conclude their pain points.

The following points are the obstacles that are experienced while receiving phone orders:

Overwhelmed with too many tabs of information to fill in.
Had difficulty browsing the menu because of the limited available screen space.
Couldn’t check and edit the long list of input orders within one page.
Didn’t easily realize more information at the bottom of the page without scrolling.

📍 Objective

The goal is to simplify the interface to make a seamless flow to make a phone order from customers.

💡 Improvements

Based on the problems identified, the process of finding the solution proceeded through iterations as the following wireframes:

❓ Why didn’t it work?

The first, second, and third renewal design was one-page type of information input with 1/3 of the space set to show the order list and other order choice requirements. We had an internal test and discussion within the company about those alternative designs and concluded that this kind of layout didn’t really solve the overwhelming pain points of seeing the information all together. Moreover, if we insisted to use the design, we’ve got small space to show each menu and make it harder to avoid much scrolling. The size of each button was also smaller to fit in the space.

Final Design

In the chosen design the information content is basically divided into 3 tabs main menu in which the user can decide freely which part to fill in first. The changes are made to provide proper spacing for each text field with the least scrolling possible so that it is easier to look at and hinders the user to miss any information. When restaurant staff receives a phone order, it is expected to be done fast and smoothly so the user needs to be able to grasp the information easily.

If the user still misses something at the end of the “order” action button, an alert icon and error message will appear right in the missing information spot to notify the user.

The main menu are consisting of:

Customer Information

In Costumer Information menu, restaurant staff needs to fill in the customer’s telephone number, name, and address. The improvements are:

Included title of the page as “Staff Input” to indicate what the whole pages are about, as well as back and close icons.
Made a clean layout and redesigned the text fields.
Added real example placeholder text to guide users on how and what exactly to type.
Made suggestions to appear when the phone number is inputted, so the user can choose and the remaining information will be automatically filled.
Provided error messages and change of color in text field outline color to show what kind of error occurs and how to solve it.

Delivery Method / Reservation

Delivery Method/Reservation are put in one menu since they are related to each other. Restaurant staff can specify the kind of order whether it is a delivery, take-out, or in-store order. After that, the estimated pick-up time and payment method should be set. The rest is how to pass the order and disposable utensils will have to be filled according to the order type. The additional improvements are:

Redesigned the dropdown options to a selection of buttons with solid color contrast for the chosen one.
Changed the layout so the user can see all the options in one go and the default option is set.
Added the detail of the estimated pick-up time with the date and exact time text field.

Order

Last but not least is a whole page dedicated to the Order menu. Here, restaurant staff can browse and choose the store, category, and browse menu. The improvements are:

Changed the layout to include both lists of menus and lists of orders on the same page side by side. The scrollable part is made only for the list to make checking and editing order easier.
In the list of orders, added the dotted lines to connect the menu name and its price to help to show it more clearly and note each for the menu or restaurant.
Redesigned the list of menu box shapes, with only names and prices to show as many menus as possible.
When clicked, made a pop-up of menu details to choose the size, toppings, and amount of order.
Added a scroll menu, in the shape of an arrow down, to notify the user that there is more to see with scrolling.

📝 Why is this challenging?

There were some constraints that I was forced to balance while designing the renewal, such as:

Limitation of layout design due to developers’ requests & preferences.
No chance to connect with real users directly to test the final design before release. Usually, the renewal design is implemented and released then Product Owner interviewed some of the clients about their experiences and lists their problems to be passed down to the Product Manager and then to the Designers & Developers.

☕️ Reflections

Through this project, I learned a lot about not only thinking about the visual but also emphasizing the needs of various aged users with hectic schedules in designing the app. One thing I wish I had the most was the time and access to do user testing. Other workloads and projects were lining up and we only had brainstorming sessions with members of the team in which I'm aware that they might have some biases with the products themselves. I hope next time I get out of the bubble and dig for richer insights from real users.