I redesigned how Rove managed medical transportation—from the first request to the moment a patient got home.
For many patients, transportation is just as important as the healthcare appointment itself. Many are recovering from surgery, undergoing ongoing treatment, living with disabilities, or managing conditions that make driving or traveling independently difficult. Some require wheelchairs, stretcher transport, mobility assistance, or a caregiver during their journey. Because of these needs, a regular taxi or ride-sharing service is often not enough. Rove Now helps patients get to medical appointments safely, comfortably, and reliably.
About product
Rove Now is a Non-Emergency Medical Transportation (NEMT) platform that gets patients to and from critical healthcare appointments — dialysis, chemotherapy, rehabilitation, specialist visits, and hospital discharges.
Project overview
The project in a glance
With a regular ride-hailing service, getting something wrong might mean arriving late to dinner, work, or an event. Rove was built to give patients with accessibility needs a reliable, comfortable way to get to healthcare. For Rove Now, the stakes were much higher. A missed pickup could mean a missed healthcare appointment. A delay could mean delayed treatment. The wrong vehicle could mean discomfort or make the journey impossible altogether.
Before, Rove Now’s operation was coordinated manually. A patient would call Rove. An operator collected the appointment date, appointment time, pickup location, accessibility requirements, and other trip details, then entered the information into spreadsheets, contacted drivers, calculated pickup times, coordinated changes, communicated with patients, and managed the trip through completion. And for a while, it worked. But as booking volume increased, the number of things they had to coordinate increased with it.
More patients meant more trips to schedule, more drivers to coordinate, more accessibility requirements to account for, and more information to keep aligned across spreadsheets, calls, emails, and texts. What had once been manageable was becoming increasingly difficult to keep track of. The operation was starting to depend on people doing more and more manual work just to keep every trip on course. And that created a problem bigger than efficiency.
- 01Patients call
ACTIONS
- Patients request transportation
- Trip details collected over phone
FRICTION
- Incomplete information
- Details misheard or forgotten
- 02Manual entry
ACTIONS
- Operator records booking in spreadsheet
- Patient information entered manually
FRICTION
- Data entry errors
- Missing mobility requirements
- 03Driver assigned
ACTIONS
- Coordinator reviews available drivers
- Driver selected manually
FRICTION
- Wrong vehicle assigned
- Scheduling conflicts
The brief was simple. Build an online booking form.
At first, it made sense. Move bookings online. Reduce phone calls. Reduce manual data entry.
But before I started designing the form, I wanted to know one thing:
Would a digital booking form actually be enough to reduce errors, or were we approaching the problem from the wrong angle?
Because the operators managed every request from beginning to end, they were the primary focus of my research. I asked them to walk me through the entire process—from receiving a request to completing the trip. I wanted to understand:
What they process, and the source of errors.
Discovery
What I learned
The more I followed the operators through the process, the clearer it became that the problem wasn’t one bad form or one missed piece of information. The operation itself was held together by too much manual coordination. I found five problems at the heart of it.
Trip information was scattered everywhere
Trip information lived across multiple places: phone conversations with patients, spreadsheets for scheduling, emails to drivers, text messages for updates. A single trip’s information could be split across five or more places, and operators were constantly moving between systems just to keep one trip up to date.
If information lived in multiple places and one place didn’t get updated, the inconsistency was invisible until it caused a problem — driver arrives at the wrong time, patient isn’t ready, vehicle is wrong.
Scheduling depended on manual calculations
Pickup times weren’t simply entered into a calendar. Operators had to work backwards from the appointment time and calculate travel duration to the hospital, buffer time to ensure the patient arrives early, time needed to account for accessibility requirements, and current driver location and availability.
Scheduling became the biggest time bottleneck. A single operator might spend 30% of their day just calculating pickup times, and every manual calculation created another opportunity for error.
Simple booking changes took too long
Booking changes were common. A patient might change their appointment time, cancel a trip, or provide a missing detail. But a small change rarely stayed small. Operators had to update the booking, contact the driver, notify the patient, and make sure everyone was working with the latest information. A 30-minute change could trigger an entire round of coordination.
Getting the patient back home created a second problem
The journey didn’t always end when the patient arrived at their appointment.
Patients often didn’t know exactly when their treatment would finish, which meant their return ride couldn’t always be scheduled in advance. When they were ready to leave, operators had to start coordinating the return trip again — finding a suitable vehicle, checking availability, and arranging the pickup. Getting a patient to care was one workflow. Getting them home could become another.
Trip visibility disappeared after scheduling
Once a driver was assigned, operators had limited visibility into what happened next. Was the driver on the way? Had the patient been picked up? Was the driver delayed? Did something need attention? Usually, they had to call to find out. That meant operators often found out about problems after they had already happened, rather than being able to see them early and act.
None of this shows up if you only ask “how do we get bookings off the phone and onto a form.” A form would have made the front door prettier. It wouldn’t have touched any of what was actually breaking.
Synthesis
The brief had to change: from digitizing the process to redesigning the system
I could have designed a form. It would have looked clean and made things easier. Patients could request rides online instead of calling, and operators would spend less time taking down the same information manually. That would have been an improvement.
But I knew it wouldn’t solve the bigger problem. The form would only make the first step easier. Everything that came after it — calculating pickup times, matching vehicles, coordinating drivers, and arranging return trips — would still need to be managed manually.
So I took what I’d learned back to the client and proposed that we look beyond the booking form and rethink the entire transportation workflow.
He agreed, and that changed the brief.
We moved from “digitize the booking process” to “redesign the entire transportation workflow.” I wasn’t just designing a way for patients to book a ride anymore. I was designing what happened after they did.
Three experiences. One trip.
Rove became a connected system rather than a single booking interface.
Patient portal
Book → Schedule → Track → Return
Patients and caregivers could:
- Submit transportation requests
- Provide accessibility requirements
- Schedule recurring rides
- Review booking details
- View trip status
- Manage return transportation
Operations platform
Review → Schedule → Assign → Monitor → Resolve
Operators could:
- Review incoming requests
- Manage trip details
- Schedule transportation
- Match drivers and vehicles
- Monitor active trips
- Handle exceptions
Driver experience
Receive → Navigate → Update → Complete
Drivers could:
- Receive assignments
- View trip details
- Navigate to pickup
- Update trip status
- Report issues
Design principles
Five principles guided the design
Before designing anything, I wanted a clear set of principles. Not rules. Just reminders of what we were trying to achieve. Those five principles became a simple filter for every design decision that followed. Whenever I found myself debating an interaction or layout, I came back to one question. Does this reduce uncertainty for the user?
Reduce coordination, not control
The system should reduce manual effort while allowing operators to intervene when needed.
Surface critical information early
Accessibility requirements, timing constraints, and trip risks should always be visible.
Support decision-making
Help operators decide faster, not replace them entirely.
Single source of truth
All trip information exists in one place, always current.
Make trust visible
A driver should understand whether a charger is current, reservable, and reliable.
Designing the experience
Designing a more reliable transportation experience
The discovery phase revealed that most operational issues originated long before a driver was assigned. Rather than redesigning individual screens, I focused on the moments most likely to create operational risk.
Guided booking flow
Replace one long form with a guided booking flow
The original brief called for a traditional booking form. I chose a different approach.
Many patients using Rove may already be dealing with the stress of an upcoming medical appointment. A long form asking for every piece of information at once would increase cognitive load and create more opportunities for missing or incorrect information. So I designed a guided booking flow.
One decision at a time. Clear progress. A final review before submission. Although the experience required more steps, the trade-off was intentional: I chose a slightly longer journey in exchange for greater clarity and accuracy.
Help patients select the correct transportation service based on their mobility needs.
Capture accessibility and assistance needs before transportation is assigned.
Provide a final verification step before booking submission.
Automatic time calculation
Scheduling recommendations, not manual calculation
Operators had to manually calculate pickup times for every trip, working backwards from the appointment time:
- Add travel duration
- Add buffer for early arrival, which medical appointments require
- Adjust for accessibility needs
- Check driver availability
As volume grew, this became a major bottleneck. I designed the system to calculate and recommend pickup times instead.
The system knows the appointment time, the typical travel duration to that location, and the recommended arrival buffer — usually 15 minutes early for medical appointments — and recommends a pickup time: “Pickup at 8:15 AM.”
The operator reviews it, can adjust if needed, and approves.
Help patients select the correct transportation service based on their mobility needs.
Capture accessibility and assistance needs before transportation is assigned.
Flexible return
The trip doesn’t end at the appointment
Once a patient attended their appointment, operators had to call them again to arrange the ride home. That meant another phone call and more operator time, another scheduling process, another opportunity for miscommunication, and uncertainty for the patient — when will they call? Will my ride actually be arranged?
So I built return trips into the product from the start. When booking their ride, patients could choose how they wanted to handle their return trip. If they already knew when their appointment would end, they could select a return time in advance. If they didn’t know, they could simply let Rove know when they were ready to leave.
From there, the system would:
- Identify a suitable driver based on availability and the patient’s accessibility needs
- Check the driver’s availability
- Calculate the route from the appointment location to the patient’s home
- Assign the trip automatically
- Send the driver the new assignment
- Notify the patient with their driver and ETA
Operators still had visibility and control throughout the process. If no suitable driver was available, the system flagged the trip so an operator could step in and arrange it manually.
Confirm that transportation has been secured and share driver details before pickup.
Allow patients to request return transportation when their appointment is complete.
Provide reassurance that the system is actively matching the request with an available driver.
Recurring journeys
Recurring rides for recurring appointments
Patients with recurring appointments — dialysis three times weekly, chemotherapy every other week — had to book a new trip each time. That meant repetitive work for patients and operators, and it didn’t reflect the reality of medical care.
So I designed recurring ride scheduling. Instead of book → book → book, patients could create a recurring transportation plan and manage individual trips when something changed. A patient attending dialysis on Monday, Wednesday and Friday could set up one recurring plan instead of booking three separate trips, then manage individual trips if an appointment moved or was cancelled.
Allow patients to schedule ongoing transportation for recurring treatments.
Review schedule details before creating multiple transportation requests.
View, update, pause, or cancel recurring transportation schedules.
Visibility
Share trip visibility across all parties
Once a trip was scheduled, patients were left waiting without knowing what was happening. Operators had limited visibility into active trips and often had to call drivers for updates. Drivers were assigned a trip and sent on their way, with little connection between what they were doing and what the patient was seeing.
The problem wasn’t that the trip wasn’t happening. It was that everyone experienced the trip from a different point of view. I designed a shared trip-status experience so that the patient, operator, and driver were all working from the same view of the journey.
Prepare patients for upcoming transportation with key trip information.
Provide real-time visibility into transportation arrival progress.
Notify patients when transportation reaches the pickup location.
Operator’s dashboard
I designed the operation behind every patient journey
The operators were at the centre of every trip. They were responsible for turning a patient’s request into a workable journey — reviewing the details, coordinating the right resources, keeping track of what was happening, and stepping in when something changed. The old process made them do too much of that work manually.
I redesigned the operator experience to give them one connected place to manage the operation, with the system taking care of repetitive work while keeping operators in control of important decisions. The experience was built around three things:
- Give operators an immediate view of trips that need action, rather than making them search through bookings or call drivers for updates
- Keep patient requirements, appointment details, timing, vehicle, driver, and trip status connected so operators weren’t piecing information together from different places
- Act quickly when something changes — review a trip, make adjustments, reassign resources, and respond to issues without restarting the coordination process
What we ended up building
What started as a booking form became an end-to-end transportation system. The original brief was to move booking online, but the problems we uncovered stretched far beyond the booking moment. So instead of digitizing one part of Rove’s existing process, we built a connected system that supported the patient, the operations team, and the driver throughout the journey. Together, these experiences connected the entire journey — from a patient’s first request to getting them where they needed to go and back home.
Outcome
What changed after redesign
The redesign changed Rove from a process that relied heavily on manual coordination into a system that could handle more of the transportation journey itself.
Fewer booking errors
Common booking errors were caught earlier, reducing the amount of correction and follow-up required after submission.
Reduced operational dependency
Operators spent less time doing repetitive scheduling calculations and could focus on reviewing the recommendation and handling exceptions.
Improved scalability
Rove had a more scalable operational foundation that could support growing transportation volume without relying entirely on additional manual coordination.
Better visibility
Patients could follow their transportation, while operators could identify the state of active trips without relying on repeated calls and follow-ups.
Final reflection
When I started the project, the brief was straightforward: build an online booking form.
It would have been easy to take that request at face value and start designing screens. But once I spent time with the people actually running the operation, I realised the booking was only the beginning. The harder problem was everything that happened after it.
Who has the right vehicle? When should it arrive? What happens when the appointment changes? Who knows when the driver is delayed? How does the patient get home when they don’t know when treatment will finish?
Those questions changed how I approached the product. I stopped thinking about the booking as the product and started thinking about the journey as the product.
That shift became the most important lesson I took from Rove. Good product design isn’t always about making the requested thing better. Sometimes, it’s about understanding the problem well enough to realise the thing you were asked to build isn’t actually the thing that needs fixing.
And that, for me, was the real work on Rove Now.
Explore more projects
Shuttrd — Creative Space Rental Web & mobile app
Designed the web and mobile applications and continue to lead ongoing feature improvements and user experience.
ChargeEasy: EV Charging App Redesign
Redesigned the mobile experience to improve station discovery, booking flow, and overall usability for electric vehicle users.
Available to work
Let’s build something meaningful together
Whether you have a project in mind, want to collaborate, or just want to say hello, I’d love to hear from you.