< Back


Problem statement: "Allow drivers to book in with a garage based on their availibility"

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

1) Empathise

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.

Based on the remote testing sessions and speaking to drivers I could start to put together a user journey map that helped to map the journey out and narrow down into some pain points for the drivers.

Customer journey map


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.

User story

“How do I book in with the garage?"

Now that we have identified that a booking system would improve the customer journey and in turn improve the business goals, I set out to gather research on how garages currently book cars in and how they would like to take bookings from us.

Garage visits

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.


We have access to all active user of the system through our dashboard, so we can quickly run surveys to gather feedback.

2) 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

Myself and the product maanger then decided a MVP would be the best option to meet our objectives and be used to gather feedback on then iterate. 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).

Defined MVP items

  • Onboarding
  • Driver flow
  • Garage management

3) Design / Ideate

I then set out designing the flows, wireframes, interaction designs and prototypes, so we could test and iterate.

Keep the personas in mind!!

Sketch and plan full end to end flow

I always start out with sketches and rough flows and wireframes as I work out the possible routes.


The first area I looked into was the driver area. We had recently released a new choose garage page and the calendar would sit on this page allowing drivers to select a date.

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.

Garage booking management

The driver side is fairly simple, however the management from the garage side will be more complex.

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.


Notification types

In system alerts, emails, text messages


Overbookings are a controversial part of the system. It's a business requirement to not prevent accepts on the system. However, until we learn from the uptake and the way the garages use the system we need to not prevent drivers from accepting a quote. So allowing for overbookings which then have to be managed by the garage is a business move that does not sit well form the user perspective.

I like to supply an example animation using principle to help demonstrate how the interactions could work. This makes the hand over easier to explain.

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 we carried out a few small changes to the system. EG: Introduced text message notifications of bookings, validation with the onboarding flows.


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.

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.

< Back
© willforsyth | Pattern Library