Case study: designing an online reservation service for restaurants

myLocali is an online booking service. It’s a centralized platform where establishments can manage various aspects of their business with absolute ease. I was responsible for the user experience design and visual design of this web‑based application, as well as for the iOS and Android companion apps and a separated booking widget for myLocali.

The main reason for creating myLocali was the absence on the South African market of any restaurant booking service. And myLocali team wanted to solve this problem. We needed to build a complex booking service that would be easy-to-navigate and search for two types of users: service providers (restaurants) and customers (their guests). Restaurants needed the ability to view and manage bookings from anywhere at any time, while guests needed the ability to quickly make a booking here and now.

What we built and how

After gathering the initial research data, it’s been decided to split the entire system into two autonomous parts: online service for guests and a management panel for restaurants.

Guests part of the system was represented by a website where people could search for a restaurant, make a booking, leave reviews and get loyalty rewards. We implemented a highly flexible faceted search that had no analogs online at that time, so people could find exact places which meet their specific preferences. The booking process was quick and the smart system automatically filled in forms for people making their experience with the site even more pleasant. There was a set of highly manageable email and SMS notifications for different occasions, as well as various reminders (about future bookings or unrated but already visited places).

The restaurants’ part of the website was different and more complex than the part for guests. The main request received from service providers was that they needed to have several options in the system to make it useful for their business. First of all, they needed to track all bookings being made in their locations. They needed to be updated if a booking was made or cancelled, if a person booking a table is their regular or a new guest. Secondly, to be able to offer their tables for booking, they needed to manage their tables, stuff, and services in the system. And they were able to do that on myLocali. Later we added a separate booking widget for service providers which they could insert on their websites. Through this widget visitors of their sites could make reservations inter restaurant to a certain date and time (though neither loyalty reward, nor complex search wasn’t added to the widget, it was available on myLocali website).

Wireframing was a huge part of my work on myLocali. It helped me and my team to explore differnet design approcahes for various situations

Challenge with tables and seats

The most challenging part of it was the ability to add tables because when a person booked a table, they could select a table for 2/4/6 and more people. But as we discovered those tables and seats couldn’t be added to the system strictly. Often restaurant staff combines different tables for certain reservations, more often when a booking needs to be for more than two people. For example, if you’re making a reservation for 6 people and there are only 3 tables for two people in a restaurant, the staff can combine these tables to accept your reservation request. And that was a problem because when a guest makes a booking, they need to select a table and to allow them to select the table, restaurants need to add the table. And since, this table may serve as a separate table or as part of a bigger table at the same time, depending on the situation, we needed to come up with a solution where people who need a table for six would be able to book it even if it does not exist in reality.

After trying different options and learning what service providers needed, we implemented the following solution. Restaurants were able to add tables with a fixed number of seats. For example, “t2” means this is a table for two people, “t4” means this is a table for four people, “t1” means this is a bar seating. There also was an ability to specify the capacity of restaurant rooms. And when the guest was making a reservation for two people, the system automatically selected one of the available “t2” for their use. It could select two bar seats if the rest wasn’t available, notifying guests during the booking that the restaurant is full but there are two bar seats available. It also could select “t4” or even “t6” depending on the restaurant policy. In the situation, when guests were booking a table for 7 people, the system searched a table for 7 people. If it couldn't find the table for 7, it automatically counted the number of available seats in a restaurant. Remember I mentioned that service providers could specify the capacity, let’s call it X. They could also specify the number of seats that must always remain free, let’s call it Y. Now, if the system finds that X-Y ≥ 7, it makes the reservation. Otherwise, the reservation couldn’t be made.

If the service providers added bookings manually (in case if someone’s called to book a table) through the system, they could combine tables depending on their guests needs. In case of a booking for 7 people, they could combine “t4”+”t4” or “t4”+”t2”+”t2” or other variations (design = maths you know). During the booking the system didn’t bother guests with these details, they could see they have booked a table for 7 people. But service providers received a detailed overview of the combined tables and those tables were already marked as “booked” in their admin.

Various mobile and web design assets

Design challenge

From the user experience perspective, the task involving tables was the most challenging for me (it might be different for the rest of the team though because as I already mentioned, we built a very complex search with a lot of criteria to select from). I had to be sure that all service providers would understand how to add tables, why we need them to add the overall capacity and, most of all, that they are free to combine tables as they usually do in their daily routine. Apart from that, there also were a few features that needed to be presented in a simple and effortless way. Also, I designed a countless number of system messages and email templates for all the possible scenarios. The problem is that all users need to receive clear feedback from myLocali about statuses of their reservation, reminders of their next bookings and myLocali messages guiding them what else they can do on the site and what benefits they can get after using theist on a regulate basis.

When I speak about “feedback from myLocali” I mean everything from small tooltips guiding you when you just started using the service, to system messages after you completing different actions on the site, to help sentences on empty pages, to notifications and reminders, and in situations when your search didn’t return any results. After the product was built, step by step, including feature after feature, apps, and the widget, even then the design work on system feedbacks still remained huge.

The result

Work on myLocali was a great opportunity for all our team. We learned a lot about new features and restaurant business and their customers. As with every our project, it was our priority to make the project that would help the restaurants grow, especially small and local ones. And at the same time, we wanted to make it easier for people to make a booking in a place that matches your preferences, whether you need a wheelchair access, free wi-fi to work or a kids room. The project was released but it is currently sunsetted.

Web app design pages