Reduce leakage
As a product team, one of our objectives is to increase conversion on our funnel. One of the areas of leakage we have identified in the funnel is receiving a quote from a garage and then clicking choose a garage.
My Role: Lead Product Designer
Team: Data analyst, product manager, copy writer, marketing
- Acceptance rate +30%
- Refund rate -80%
Achievements
"Allow drivers to book in with a garage based on their availability"
Problem statement
Reduce refund rates by -20%, increase acceptance rate by +5%
KPIs to gauge success
Empathise and research
I approached drivers through our customer contact team and also ran remote usability tests. This helped to define pain points in the process and work out from the findings what a potential improvement would be.
Usability testing
Usability testing and interviews highlight some pain points in the process.
Feelings: Frustrated, worried about price, unsure of next steps.
Thoughts: Not sure how to book in, how long will the job take, do I need a courtesy car, why am I getting phone calls from garages.
The current flow is for drivers to call the garage to book in. Introduce a booking system for the main funnel flow will cut down on these pain points.
As a driver I want to be able to see the availability of a garage and book in.
Key user story
Garage visits and interviews
We went on the road to gather research into how garages currently book drivers in once they have had a job accepted. We visited 4 garages and spoke to the mechanics and office admin who used the system to talk to drivers and book them in.
Surveys
We have access to all active user of the system through our dashboard, so we can quickly run surveys to gather feedback.
"We use multiple websites to win work, and then book drivers in over the phone or have drop ins. So these all need to work together."
Garage feedback
Define
I gathered all the results and held a session consisting of affinity diagrams, post-it notes group the problems into sections and decide on the best way to approach the problem:
- Garages use multiple systems to manage bookings
- Some use pen and paper
- Most will not turn away bookings
- They accept a specific number of jobs per day, this could change depending on the type of job
- Some have visited and some have drop-offs
Defined MVP items
Define a MVP and level of functionality. This was based on business objectives and also on the drivers and a prioritisation matrix.
- Allow morning or afternoon drop-offs.
- Allow the garage to set the number of drop-offs they will take per day.
- Allow for overbookings (Business objective).
- Onboarding
- Driver flow
- Garage management
Design and Ideate
Sketch out ideas
Sketches out rough flows, wireframes and ideas so I work out the possible routes.
Driver designs
After mapping out the flows I moved onto the more detailed wireframes and UI designs to tests.
Design problem | Change date
User findings raised the need to allow a driver to change a date of their booking. Either due to a mistake or a change in circumstances.
"Ahh wait I picked the wrong date I need to change it"
User comment
Garage booking management
Problems to overcome
- Change the mindset of the garage that drivers will book in through the system.
- Garages sometimes miss bookings so we need to make sure that we dont have drivers turning up for bookings that the garage is unaware of.
Garages use multiple systems so sometimes miss bookings. Update alert systems with in system alerts, emails and text messages.
Notification types
Garages can easily manage dates, toggle their availability and manage their bookings.
Notification types
Design problem | Overbooking
Buiness goals meant we couldnt stop a driver booking in. So I designed a overbooking system that notified the garage that an action was required.
How will we notify a garage that a booking has been taken on a day that they could be full, and how do we notify the driver that the garage may be full.
Interation problem statment
Garage On-boarding
On-boarding of the user is of huge importance when releasing this feature. The garages can opt in to use the new functionality.
Usability tests with mechanics and drivers
Once we had a working version to test the end to end flow, I approached several garages that had indicated that they would like to be involved in the process of developing a solution.
In person site visits: I visited four garages and watched them use the system. Asked them questions and gathered feedback.
Remote sessions: I carried out remote sessions with garages further away to gather feedback.
Following the feedback I Introduced text message notifications of bookings and validation with the onboarding flows.
Release
A session with the product team was then held, to work out how we want to release the booking tech, how we are going to monitor and how we are going to gather data on the release.
Decisions: Release nationwide as we have on-boarding to allow mechanics to authorise driver bookings. Run hot-jar, set up GA dashboard, Data team daily feedback reports.
Whilst the tech was in QA we decide to run a quick A/B test to change the main CTA on the comparison page. We are introducing the new booking tech which will involve changing the CTA text, will changing the text have an adverse effect or a positive effect on conversion? We use googles https://optimize.google.com/ to run quick tests like this.
Refund rate -80%, and accept rate increased by +30%;
Results
Next steps: Usability tests to refine and iterate on the flow. Then using our user journey maps, and research I will introduce the availability into other areas of the flows to increase conversion.