Carpool
Employees could reserve company cars. The brief looked like a booking-product problem. The research said otherwise.
UX research · Service design · Design explorations
The interface had real usability problems. The dominant constraint was still vehicle availability and operational readiness.
Client and product details have been anonymised. Interface imagery has been reconstructed for portfolio purposes.
- Research evidence
- Project context
- Interpretation
- Reconstruction
- Design exploration
An internal vehicle-pool benefit
People reserved company cars for leisure or work. If the booking flow felt broken, it was easy to assume the fix sat in the product.
What the research already made visible
An editorial map of documented evidence. Not analytics. Not invented rates.
Every panel below is mapped to the source research before it appears here.
Vehicle unavailability was the primary challenge.
Usability concerns became secondary when vehicles were unavailable.
This service had a capacity problem that showed up through the booking experience.
Carpool was an employee benefit: an internal system for reserving company pool vehicles for leisure or work.
Next usable opportunity. Weekends matter.
Leisure interviews were the strongest sample. Work and operations still needed deeper research.
- Contextual inquiry
- Leisure-user interviews
- Personas
- Expert review
- Hard to find available slots
- Planning months in advance
- Unexpected cancellations
- Unclear confirmation
- Unclear reservation status
- Unclear availability
- Unclear rules
- Operational uncertainty
- Charging time
- Vehicle inspection
- Maintenance
- Vehicle condition
- Reservation limitations
- Pickup and return processes
Greater flexibility / next available slot
Documented need contrast. Not a claim that the product already split these flows.
Charging and inspection sit between return and the next usable booking.
Conceptual service model derived from the research. Not an official SOP.
Booking is one node. Operations and readiness sit around it.
Documented late cancellations could arrive without a clear reason or alternative.
We thought the platform was the problem.
If booking felt broken, rebuild the booking product. Reasonable. Incomplete.
- Platform
- Booking
- Car
Before designing a solution, we investigated the service.
A platform rebuild was framed around roughly 6 to 12 months. That figure is project context, not a research metric.
We looked past the screens
Operations told us what happened between bookings. Leisure users told us what it felt like to wait. An expert review walked the live product line by line.
Pick-up, drop-off, charging, inspection, policies, condition, fines.
Search, reserve, cancel, and whether the wait was still worth it.
Leisure flexibility, work precision, fleet operations.
Rules timing, history, confirmation, error clarity.
Strongest on leisure use. Work bookings and deeper operations were flagged as next steps.
One leisure user put it plainly: when cars were available, the interface stopped being the main complaint.
Three relationships with the same service
Behavioural roles from the research, not demographic posters.
Aires
Flexible demand
The next usable opportunity. Weekends matter.
Ricardo
Fixed commitment
A car on a fixed date, inside a precise window.
Rita
Fleet and requests
Demand versus readiness between one booking and the next.
The problem wasn't finding the booking button.
Vehicles
- Compact EV 01Available to reserve
- Compact EV 02Available to reserve
- Estate 1Listed · no usable slot
Try another day
People hunted for open days, planned months ahead, and still met unavailable options that looked selectable. There was no waiting list.
Even a reservation could disappear.
Jan to Sep
One documented case: booked in January for September, then told roughly twenty days before that the car would not be available. No usable explanation. No alternative.
From leisure-user research. Not claimed as every reservation.
Available didn't always mean ready.
Return
Electric leisure cars need charge time. Inspection sits between return and the next booking. A free calendar cell can still mean a car that cannot leave yet.
Work and leisure needed different things.
Next available weekend
One interaction model served two jobs: fixed commitments and flexible opportunity. The research recommended letting people declare intent.
The system knew the rule before the click.
Limits such as one active leisure reservation appeared after Reserve, not before commitment.
Status was hard to see when it mattered.
- Compact EVOpen
Defaults could hide future bookings. Important status sat late in the table. People opened tickets for reservations that already existed.
Scheduled time is not proof of what happened.
- Pickup
- 09:00
- Return
- 17:00
Times below are illustrative.
Illustrative times
The research recommended logging actual pickup and return, for accountability when plans change.
Vehicle unavailability was the primary challenge. Usability was secondary.
The interface had real problems. That finding does not clear the product. It reorders the problem.
From “how do we improve booking?” to “what makes a booking true?”
The platform was only one layer of the problem.
Step out from the booking layer
Reserve
What software could help, and what it could not solve alone
Software could improve
- Availability discovery
- Earlier rule disclosure
- Status, confirmation, history
- Cancellation reasons
- Readiness signals, if data exists
- Work / leisure intent
Software could not alone
- Create fleet capacity
- Erase charge-time physics
- Invent inspection capacity
- Prevent every maintenance cancel
- Make scarcity feel abundant
Tell the operational truth earlier. Rebuild only if the rebuild aims at the dominant constraint.
If a platform takes 6 to 12 months, what problem is that time for?
Project context, not a research metric. No invented ROI.
- New platform
- Better booking UI
- Better access?
- New platform
- Better booking UI
- Same fleet
- Same availability constraint
Project context
The research challenged whether rebuilding the platform would address the dominant constraint.
What the research opens for design
Ask when a car is needed before browsing models.
Make charging and preparation visible.
Fixed window versus next available.
Status that answers what is happening now.
Reason and next step, not silence.
Log pickup and return when they happen.
The most useful design decision was deciding what needed to be solved first.
The research changed the question
A sharper decision frame. Not a launch story. Not invented savings.
How do we build a better booking platform?
What is actually preventing the service from working?
The booking platform was the place to intervene.
Real interface problems, under a deeper availability and readiness constraint.
The investment question moved from UI rebuild to service truth.
Months of platform work only help if they aim at the constraint people actually feel.
Limits
Internal tools inherit the physics of the service they represent. When that service is scarce and operationally buffered, the product’s first job is to be truthful.
The sample was leisure-heavy. Work evidence was thinner. Operational depth was unfinished. Those limits belong in public.
Client and product details have been anonymised. Interface imagery has been reconstructed for portfolio purposes.