← {{ backLabel }}

Book a Test Drive Online

Designing an end-to-end test drive experience for customers and the Curbie team.

Curbie didn't have a way for customers to schedule test drives online. Interested customers had to call or email support to arrange an appointment, and internally there was no shared calendar for test drives — making it difficult for the team to understand vehicle availability, coordinate appointments, and avoid scheduling conflicts.

I led the end-to-end design of a new online test drive experience — from customer research and journey mapping through prototyping, usability testing, and implementation — giving customers self-service booking and giving the Curbie team a centralized calendar to manage appointments.

The problem

Buying a vehicle is a high-consideration experience — customers often want to see and drive it first. At Curbie, arranging that was entirely manual: a customer would contact support, who then had to coordinate the appointment internally. The team didn't have a reliable view of test drive availability, since each member kept their own calendar.

Understanding the customer experience

Before designing the booking experience, I wanted to understand what customers actually experienced at a dealership. I interviewed people who had recently gone through the process or were interested in purchasing — focusing on what motivated a test drive, what created confidence or uncertainty, and what made the process frustrating. The test drive was more than a scheduling problem; it was one step in a much larger vehicle-buying journey.

Mapping the experience

I created a persona and empathy map to help the team understand the customer's goals, concerns, and expectations, then mapped the journey from discovering a vehicle through scheduling and completing the test drive — surfacing opportunities to reduce friction before the customer even arrived.

Customers needed to feel confident that:

• The vehicle would be available.
• The appointment would actually be scheduled.
• They knew where the test drive would happen.
• The process would be straightforward.

Understanding the internal workflow

I interviewed the Curbie team to see how test drives were currently scheduled. Because each team member had their own calendar, support couldn't easily answer "when can this vehicle be test-driven?" or "how many test drives are already scheduled?" The booking experience needed to solve an internal coordination problem as much as a customer-facing one.

Looking beyond the obvious solution

A competitive analysis of other automotive marketplaces and booking experiences surfaced a feature from a competitor: delivery test drives, where a vehicle is brought to the customer instead of visiting a dealership. It was getting positive feedback, so I brought the opportunity to stakeholders, and the team wanted to explore it.

This changed the scope from "book a test drive at Curbie" to "choose how you want to experience the vehicle."

Designing the new experience

The new concept needed to support two options: visit Curbie, where the customer picks a time to test-drive at Curbie's location, and delivery test drive, where the vehicle comes to them. Supporting delivery introduced a new requirement — location — so I explored Google's mapping capabilities, letting customers see their address on a map and adjust the pin, or use their current location with permission.

From concept to flow

I built a new user flow connecting the customer-facing booking experience to the operational requirements behind it: vehicle selection → test drive option → date & time → location → customer information → confirmation — accounting for different outcomes depending on whether the customer chose in-person or delivery.

Exploring the interaction

I started by sketching different approaches for presenting the two test drive options — aiming to make the choice clear without feeling like two completely different processes — and shared the concepts with stakeholders early to narrow the direction.

Designing the booking experience

The wireframes brought the journey into a clear, step-by-step experience — one decision at a time. For the delivery option, the flow introduced address selection and map confirmation, letting customers verify where the vehicle should be delivered rather than relying solely on a typed address.

Testing with users

Once the core designs were ready, I built an interactive prototype and tested it with users — checking whether they could discover how to book, understood the two options, could complete the flow, and whether delivery made sense.

Designing for the team

The customer-facing flow was only half the problem — the team also needed a better way to manage appointments. We introduced a dedicated test drive calendar giving a centralized view of which vehicles were scheduled, when, and how many appointments were coming up, reducing the risk of double-booking and making it easier to manage operational capacity.

Building with existing technology

Before development, I explored existing calendar booking APIs rather than building a custom scheduling system — the team decided to purchase and integrate one instead of spending significant development time recreating functionality that already existed.

Working with Engineering

I provided detailed specs, answered questions, and collaborated on visual implementation, reviewing visual accuracy, interactions, booking states, edge cases, and responsive behavior as it was built — staying involved through release to make sure the implemented experience matched the intended journey.

Results

• Online booking — customers could schedule test drives without calling or emailing.
• A centralized calendar — the team gained a shared view of appointments, reducing conflicts.
• Delivery test drives — customers gained an additional way to experience vehicles.
• Validated experience — 87% completion rate and a 4.4/5 satisfaction score across five participants.

What I learned

• Design the entire service, not just the interface. The booking flow depended on internal scheduling, vehicle availability, and appointment management just as much as the UI.
• Research can uncover opportunities beyond the original problem. Competitive research expanded what the product could offer, not just validated the original idea.
• Don't build what you can buy. Exploring calendar APIs early saved significant development time.
• Internal workflows matter. A great customer-facing experience can still fail if the operational workflow behind it doesn't work.

← {{ backLabel }}