Redesigning the Booking Flow at Drover to Increase Conversion
At Drover, one of our main design goals is to make our homepage as clear as possible to simplify the sign up process. To achieve that, we’ve recently made various changes to our platform. The most important change we’ve made in this regard is a new booking flow that simplifies the process of requesting a booking/subscription for Drover. In this article, I’m going to explore our process for tackling this problem from start to finish.
Why redesign?
In the past, simplifying the booking flow was not a top priority due to us having a different business focus (i.e., we were focused on B2B sales for which our website is not too important). As we evolved, the company changed its focus towards consumers. As it turns out, the average consumer is expecting an experience that is similar to the ones they regularly use on other e-commerce platforms (Jakobs’ Law).
However, our previous sign up flow was causing us to lose customers. The process was confusing and we were displaying too much information at the same time. In other words, we were overloading the user’s cognitive capacity.
With this in mind, we started the research phase.
Research Phase
I started by shadowing the customer support and sales teams. I noticed that a lot of people needed help booking a car. I heard many users complaining that there were important fields missing (e.g., additional drivers on their booking), and that the pricing model wasn’t clear to them. But the most disturbing thing is that we were getting booking requests from customers who didn’t understand what they were doing — they didn’t want to rent a car at all. This was problematic, and so we needed to improve our booking process as quickly as possible.
After understanding the experience we were providing, we defined a few goals:
- Improve Drover’s subscription experience in order to create a clear and trustworthy path for the customer to book with ease
- Increase the number of returning customers
- Reduce the number of people who need to call to ask for help
To contextualize, on our previous flow you would find the subscription form on the right side of the product page. In this form, you would see several sections:
- Subscription type
- Mileage package
- Add additional driver
- Delivery
- Price breakdown
- Payment method
- “Confirm & pay for subscription” call to action to make to assemble the booking request
It was difficult to distinguish between the price which needed to be paid on the spot and the monthly fee.
We were also not clearly explaining to the user that this is just a subscription request and they would have to provide us with more data about them in order for them to be approved in our system.
Informal talks and meetings with multiple teams at Drover were the next step in order to understand where we could do a better job to improve the user flow. We discussed many things, including the following:
- Splitting our current booking form by multiple logical and numbered steps, thus defining clear expectations regarding the status of the process to our new customers
- Making sure that we were clear with the copy provided, clearly stating that the first step is a request and not a full booking
- Customer’s perception of their experience is directly dependent on their expectations, and on whether these expectations are met
- Awareness of the customer’s short memory. Customers shouldn’t have to remember information from one part of the form to another
- Making sure that our users knew what the next steps after the request are
- Mobile experience is key, since we have more users using mobile devices
Design Phase
After the research phase, I started exploring various UX flows using wireframes.
When we reached a point where we were happy with a specific wireframe layout, we started scheduling meetings with stakeholders and with the teams that frequently talk to our customers to get their input on the direction that we thought that was the right one.
Overall, everyone was very happy with our wireframes (but we still had a lot of work to do). However, having this flow shared with all the teams was a great step in the right direction. Talking to other teams allowed us to see what our next steps should be.
As an example, in the first version of the flow, we weren’t considering the “Available From” date for our cars. When talking with stakeholders and other teams, we felt that we should be informing the user of when they could book each car. Besides this one example, there were other things that needed some work, of course.
Polishing, Handoff and Testing
When we were reaching a point where our designs were approved but 95% final, our team started to work on the implementation side. But this was not straightforward, since we were also building our design system at the same time. We were multi-tasking and trying to prepare several deliverables as fast as we could, so we felt the need to go back a couple of times, to revisit certain UI details.
Our process involved working really really closely with the QA and Engineering teams in order to ensure that we would ship the best booking flow that Drover has ever seen.
Going Live (May 29th) + Results
Going live was a very smooth process due to the hard work of the Engineering team and the results came in almost immediately.
By June 3rd, we had over 100 bookings requests made online, which was huge for Drover. Consequently, the number of people calling in for help dropped a lot.
Another great sign was that 94% of our customers are saying that they are planning on renewing their subscription with us.
Improvements and Final Notes
After going live, we’ve been tracking user data and watching Fullstory recordings. This has allowed us to make some small improvements. For example, we recently changed some selectors from increments to a dropdown:
Due to the nature of our business, a lot of steps are more complicated than we’d like them to be. For example, our requests have to be manually booked and we have to ask a lot of insurance-related questions as part of the booking. Moreover, we also ask for a variety of documents which makes the flow take longer than we’d like.
In the near future, we still want to improve our search page to allow users to find the right car for them more easily. One way we could do this is by having “Similar Car” suggestions.
Finally, I’d really like to improve the sign in/sign up process when requesting a booking. Ideally, the user doesn’t have to sign up until later in the process. This should simplify the flow as well as minimize the dropoff rate early on.
