Initially, I thought the first focus was on redesigning the UI first, and then tackling the UX. As I talked with the team, my manager actually wanted me to completely think outside the box and asked me to come up with an ideal booking experience.

Long conversations with the senior designer and the product manager helped me learn about their ideal wishful thinking of the project. I made sure to accommodate their ideas, and give a good mix with my own ideas in these wireframes.

The idea focused on "How to help a guest book a reservation fast and efficiently". How fast can they scan the calendar and figure out the date? How can we reduce the amount of clicks they have to make to figure things out? How do we give them information on seating areas, and experiences in an efficient way? There were a lot of ideas to consider.

The project would have been pretty simple if the booking widget only had to accommodate one restaurant. But that was not the case. There were various types of venues out in the wild, and the widget had to accommodate all of them as much as possible.

There were restaurant groups with different types of venues under one group name. There were franchise restaurants which had the same restaurant in various locations. Venues in Europe need multiple language settings. The widget had to look good in various branding colors and images they upload. There were fine dining venues, which focused more on experiences. There were nightlife venues which needed a duration picker in the widget. The list goes on. The design team and the leadership team had to discuss once a week on how to navigate all of these different venue's situations and come up with a design that can possibly accommodate every venue.

Another big challenge we faced is the fact that we didn't have much data on how people were using the booking widget. As there was not much data, it was difficult for us to decide the design path.

Top image shows some initial designs I worked on right after the wire framing phase. Another unique challenge to this project was the fact that the widget needed to be flexible regarding UI style. The widget needed to take in various different venue's brand colors and make it look good.

The current widget allows so much customization of the widget and that was a blessing and a curse at the same time. When the venues used it right, it looked amazing. But a lot of venues end up not customizing the widget at all, keeping it in the most basic form. The design team all agreed on taking out most of the customization settings and giving them the best default design. Customization would be limited to updating header image, logo, primary color, secondary color, and fonts.

Before narrowing down how many colors the venue would need to represent their venue, I needed to dig into our existing client's venue and try fitting their branding into the new design I was working on. Leuca, Locanda Verde, and Lafayette are venues from the NoHoHospitality group. By testing out with real venue's branding, we decided that venues only need a maximum of 2 colors for their branding. 

As my manager insisted on designing an ideal booking experience, we put together this vision storytelling presentation for the leadership team. It was a chance for us to showcase our best ideas for the booking widget that had no technical limitations.

We brought in ideas of how to use the booking widget with the influencers, as a marketing tool. We thought of combining the reservation widget with the existing events and waitlist widgets as well. This presentation session was focusing on putting the north star of where we want to go in 2 to 3 years in the future. We had to sell the idea of how this new booking widget can bring a huge difference in our product.

The top image shows the first designs the team settled on. Our biggest goal here was to show availability right away when the guest arrives on this widget, instead of making them select guest number, date and time, and then click on the "search" button. We realized a lot of people book within 7 days. That data brought us to put a week calendar for the users to easily navigate through the dates.

With this design, we got in a call with 6 different clients. We presented this new design to them, and asked for their first impression. Overall it was a great success, and they gave us great feedback on what they wanted for the booking widget.

Most important fact we learned from our client calls is that these designs need to be "Nana Proof (Grandparents proof)" according to the actual client's words. A lot of these restaurants are fine dining restaurants, with old demographics as their main customers. The booking widget had to be easy for elderly people to understand and be able to book.

There were many opinions on how guests should search for availability. Our initial idea was to make them search for guest number, date, and time, which is the same as our current widget. On the other hand, the leadership team asked if we really need the time picker. Instead of selecting time and showing 12 availability spots around that selected time, they asked if we can show the entire availability for that day. This was an ongoing debate since the beginning because availability would be different from venue to venue. For example, a busy restaurant would not have many available time slots shown. But 24 hour venues would have too many time slots to show.

This sparked us to conduct an internal user testing, selecting people in different departments who haven't seen the design at all. Version A was to use our existing design with the time picker. Version B use the design with guests and date pickers. Version A will show 12 available time slots around 7pm, while Version B will show all available time slots on that date.

Our goal was to see how people figure out the design and fulfill the given task. We also wanted to make sure people understand the week calendar. 

We conducted a total of 10 user testing. Task 1 was a simple task where we asked them to book a reservation for this week Saturday for 4 people at 6pm, patio seating, and there was availability right away. While Task 2 was a little bit more complicated where 2 weekends were not available, we asked them to book any available Saturday. In the end, we realized there was not much difference between Version A and Version B.

Designs without the time picker showed 24-30 time slots per day, but people were still able to find what they needed without a problem. However, one common problem we were seeing was the fact that people were getting the week calendar confused as a guest picker. Especially because the week calendar started as the early week of the month, starting from 3rd through 8th. The participants all agreed if the week calendar started from mid calendar, they wouldn't be confused.

Another interesting fact we learned was that people located in New York seemed to be less overwhelmed with seeing a lot of time slots in a day as they are used to booking with Resy, Sevenrooms' competitor. Resy doesn't have a time picker in their search, and allows you to see the entire day's availability. As this product is more widely used in the NY region, people seemed to be used to seeing this type of design. 

After the user testing, we decided to take out the time picker. Instead we decided to put the time picker under filters, the feature we decided to work on right after pushing out this MVP.

The top and bottom screenshot shows the first MVP design we decided to build. The top shows the search & availability part, the bottom design shows the time slot description, upgrades, and the checkout page. While the engineer team is working on it, the product team decided to work on the filters design.

While working on the project, I realized how much I underestimated the scope of the project. There was a lot of hidden logic that nobody fully understood, and there were many aspects in the booking widget that we had to consider.

Compared to other projects that were going on in SevenRooms, this was the only project that did not have clear personas, and it was difficult to accommodate everybody's opinion. Every venue had different demographics for their diners. Every venue was in different circumstances. Most of all, it was hard to navigate through different people's opinions and feedback from our own team because everybody has experience booking a reservation and they all had their own version of what the best booking experience should be. I would have my own opinion on what the design should be, but it can be easily overridden by someone else's opinion. We would debate on things that made us go in circles. In the end, I was glad that we settled on a design that could be built, so that we could test it out and get real results from the guests.