Creating a reservation request is the most important interaction on AVVAY. For guests, it means getting their reservation initiated and for hosts, it means revenue for their venue or space.
When the booking widget was first designed a focus was placed on stability and functionality. We knew the experience would have to be improved in the future so over time we gathered data through funnel metrics, user session recordings, and raw data to determine what the pain points were and where we need to improve.
We knew if we could simplify the booking UI for guests it would lead to a faster and smoother process which, in turn, would lead to more reservation requests. One of the primary ways we achieved this was to reduce the number of actions the guest had to perform to create a reservation request. For example, looking at our data we knew that the largest segment of users only requested one day. So we eliminated the required end date field and only displayed it to the guest if their reservation would take place over multiple days.
The biggest point of friction for hosts was parsing reservation request information. To accept or decline a request hosts want to know what the reservation use is for. In the first iteration of the booking widget, we prompted guests to provide reservation data like attendee amounts and use in a free form text field. This text field wasn't required and therefore had a very low engagement. This forced hosts to either decline the request based on lack of information or accept it and ask for additional information in a follow-up email. This back and forth between both parties often contributed to dropped requests. To solve these issues we introduced 2 new interactions into the widget to require that the guest provide information on what reservation was for as well as tell us whether or not the reservation would have over a certain number of attendees.
Below is a sampling of some of the wireframes that I designed. The selection of artifacts below displays one potential set of screens for a single path through the widget.Below is a sampling of some of the wireframes that I designed. The selection of artifacts below displays one potential set of screens for a single path through the widget.
The visual design for the booking flow employed preexisting design patterns and components already in the product. This ensured there would be a consistent visual experience for the customer. Our brand color red was used to call out the most important interactions for the user. Our brand teal color was used to convey lower priority actions like links and alternate buttons. Sizing of textual elements was also used so the user had a sense of priority and importance to copy.
Although additional friction was added on the guest portion of the experience, the quality of data in the request increased which led to a faster and smoother process for both parties. We used the "time to completion” metric to measure the effectiveness of this iteration. Analyzing funnel data in Heap we saw time to completion decrease which led to higher numbers of reservation requests being generated.