BlueSG
BlueSG had cars available for growth, but too few places where customers could reliably return them. I led the service and product work for a charger-less parking model, from discovery through launch measurement.
A short project brief before the detailed story: the setting, my responsibility, the people involved and the outcome we were working towards.
Third-party charging coverage limited where BlueSG vehicles could operate. At the same time, unclear availability and a demanding reservation flow made the fleet feel scarcer than it was. The work had to address the operating model and the customer experience together.
The number of cars was not the main constraint. Customers and operations needed certainty about where those cars could be returned.
Behavioural, operational and qualitative evidence did different jobs. Together, they helped define what the team needed to solve before choosing a direction.
Only 36% of 350K home-map visits progressed to reserving a car or parking location; 64% dropped before reservation.
Perceived availability was partly an information and decision-load problem—not only a fleet problem.
Unclear map states, five competing options and low-readability controls made it harder to choose with confidence.
The product needed fewer decisions, clearer availability and stronger accessibility.
Eight cross-functional participants spent 180 minutes exposing unknowns around charging, station operations and reliable end-rental confirmation.
The solution had to work as an operational service before it could work as a UI flow.
The blueprint connects the customer journey, product behaviour and operational responsibilities across the same sequence.
Looks for an available car and a workable destination.
Map and station information distinguish what can be reserved and returned.
Availability rules combine vehicle, battery and parking-station states.
Chooses a car with confidence that the journey can be completed.
A simplified reservation flow reduces competing choices.
The system holds the correct vehicle and destination conditions.
Travels with a clear understanding of the return model.
Guidance prepares the customer for a charger-less return.
Operations can see the rental and expected parking location.
Parks and scans the station QR code to confirm the location.
The app guides scan, evidence capture and end-rental confirmation.
The system verifies the station and flags exceptions for operations.
Receives a clear completed-rental state.
A visible confirmation removes ambiguity and repeat attempts.
Operations can manage vehicles, stations and exceptions beyond charging-only locations.
Scroll horizontally on smaller screens to follow the complete service.
Explore the original discovery boardThe artefacts mattered when they helped the team choose. These are the questions, evidence and decisions behind the final direction.
BlueSG had vehicles, but charging-site coverage limited where they could operate.
Expand the service model to charger-less parking rather than treating vehicle acquisition as the answer.
Hardware options differed in installation effort, cost and lead time.
Use a QR-based proof of concept as the quickest practical path to reliable end rental.
Abandoned vehicles, exceptions and system states crossed customer, product and operations boundaries.
Design one future-state journey with both user and operational lanes.
The operating service and the interface formed one system. Each lens addressed a different part of the same problem.
Shaping the ecosystem, hand-offs and operating model.
Turning service decisions into clear, usable product behaviour.
A three-hour Assumption Smash with eight people from Product, Operations, Management and delivery separated known facts from guesses. It showed that charging coverage, station operations and end-rental confirmation mattered as much as the number of cars.
We mapped the future customer and operations journeys together. Comparing hardware options against cost, installation effort and lead time led to QR confirmation as the most practical proof of concept.
I translated the agreed model into reservation, driving and return flows. Wireframes resolved the main decision points before the team invested in detailed visual design.
Four usability sessions across ten tasks exposed errors and comprehension gaps. After iteration, the shipped journey was instrumented in Mixpanel to track drop-off and time on task.
I built a fully functional Figma prototype, recruited participants who matched the study criteria and used task-based testing to validate whether people could understand availability, choose a location and move confidently towards a reservation.
The selected station was easy to lose within a visually dense map.
Strengthened the selected-location state and surfaced the station name and address as a single, scannable block.
Vehicle and parking information competed for attention at the moment of choice.
Created a clearer information hierarchy, with progressive details for the car and the available parking options.
The primary action did not make the consequence of the current selection explicit enough.
Made the main call to action respond to the selected station or vehicle and kept it consistently visible at the end of the decision path.
With four sessions, I treated the results as directional usability evidence rather than population-level proof. The value was in finding repeated friction quickly, improving the design and pairing the prototype results with post-launch behavioural data.
The final interface connected three moments that previously felt fragmented: choosing a charger-less station, keeping the return reservation visible during the rental and completing end rental with clear vehicle checks and QR guidance.
Station, vehicle and parking availability are grouped around one clear reservation decision.
The reserved return location and battery requirement remain visible throughout the active rental.
System checks, parking context and QR instructions make the end-rental sequence explicit.
These constraints affected the direction, the order of work and the compromises made with the wider team.
The team could not add charging locations wherever demand existed.
We separated parking confirmation from charging and treated charger-less stations as a distinct service type.
A more robust physical installation could improve certainty, but it would delay the pilot and cost more.
I compared the options against effort, cost and time to launch. QR confirmation gave us enough reliability to test the model without committing too early.
A simple customer flow still had to account for wrong locations, incomplete evidence and abandoned vehicles.
The future-state journey included system checks and operations exception paths instead of designing only for the happy path.
The launch data showed movement in the reservation funnel and weekly rentals. Prototype evidence came from four usability sessions covering ten tasks, so I treated those findings as directional rather than population-level proof.
Explore the original discovery boardThe operating model expanded beyond charging-only stations.
Reservation drop-off fell while weekly rentals increased.
Operations gained a lower-cost way to manage return locations.
The team had a measurement plan for conversion, idle time and support volume.
The most important move was treating the parking model, the end-rental flow and the operations workflow as one problem. That gave the team a service it could run, not just a cleaner reservation screen.
The early workshop stopped us from polishing the reservation flow before we had agreed how a charger-less return could be verified and supported.
I would run a staged station pilot and compare end-rental success, exception rate, vehicle idle time, redistribution effort and support contacts by station type.