CharterUp

Shuttle trip monitoring

Context and background

CharterUp is the biggest player in the chartering transport industry in the US and Canada. This case covers the shuttle trip monitoring feature, piloted during the San Francisco shuttle expansion and later rolled out to bus monitoring across the platform. From fragmented spreadsheets and manual check-ins to a real-time monitoring tool that the ops team and end customers could actually rely on.

role and scope

user research, user testing, prototyping, documentation, UI design

stakeholders

2 product managers, 7 engineers, CEO validation

timeline

~7 months from start to finish

tools

Figma

Book a bus at CharterUp

What got us here in the first place?

How do you rate our trip monitoring?

2/5

What our support team wants

actual ETAs

reduced spreadsheet workload

incident reporting

birds-eye view

What causes the most friction during trips for our customers?

74%

no real-time updates

61%

inaccurate ETAs

48%

no driver contact

22%

unclear pickup spots

“There's no way to tell which MLK Avenue we're talking about. Half the country has one.”

support team member

growth opportunity

Golden opportunity in the expanding shuttle market around the San Francisco Bay Area

The problem

Monitoring was fragmented and unreliable for both the operations team and the end customer. Dispatchers had no real-time visibility into trip status, and passengers were left completely in the dark about where their shuttle was, leading to frustration, missed connections, and a flood of inbound support calls that the team had no scalable way to handle.

The challenge

Our monitoring system was a mess. Neither customers nor office workers wanted to use it, and honestly, it's hard to blame them. The whole process was deeply manual, relying heavily on calling people and waiting for someone to pick up and have an answer. That wait was so time-consuming that it wasn't unusual to go hours without a single update on an active trip. How can we improve our monitoring system to actually accommodate for the needs of the business?

The opportunity

Shuttle monitoring presented the ideal starting point: a contained, geographically localized scenario operating within the San Francisco Bay Area. With the return-to-office movement gaining strong traction in 2025, corporate shuttle routes were expanding fast, and a well-designed monitoring tool built for this context could scale directly into the broader bus network with massive growth potential already in motion.

Desk research and references

How does it work today?

Teams usually set up war room-like operations for monitoring: a chaotic but somehow functional setup where everyone is watching the same screens. Behind the scenes, everything gets tracked via a really big and old spreadsheet that has seen no version control or audit trail and is 100% not a source of truth, since many teams change it over time without coordination. The usage of CoachRail, CharterUp's management tool, was subpar. It served more as a contact book and schedule checker than an actual tool people could rely on to get anything done.

Who solves visualization well?

The obvious answer would be Uber or any live transport monitoring tool, but they don't scale well for this use case. You're usually tracking one trip at a time, not dozens spread across the US simultaneously. After thinking for a while, Flightradar24 emerged as the best analogy: a crowded space packed with information that can be filtered and focused on when needed, giving a whole team the ability to zoom in on what matters without losing the broader picture.

Flightradar24 — if we can track planes, why can't we track buses?

Research and first iterations

Research

Research for this project was quite fast and relatively easy. We already had a documented process for the day before, since it was already running. We set up a few shadowing sessions with some operators and watched them take and make calls for a few hours on different shifts, both on the day of and the day before the trip. Changes between night and day shift were not so proeminent but night shift was significantly harder since they'd serve the whole US rather than one or two time zones.

After that, we went to draw the flow for both the day-before and day-of scenarios. Since the day-of was brand new, we spent more time drawing it and discussing with stakeholders and among ourselves. Regarding the day before, it was straightforward to make some changes to the actual tool and tweak the experience.

research type

User interviewsShadowing

time spent

~4 weeks

Results

Day before was really tribal and had less interaction between different tools
Day of was a mess, people jumped between 3 to 4 different tools and made calls at the same time
Most of our operators had two monitors or at least a divided screen to accommodate all the information
Spreadsheets were filled in by both day and night shift crews and had a confusing hand-off and update logic
The usage of a US map with time zones so they knew when to call for an expected delay was a real surprise

First iterations

What was explored

As a first draft we ended up taking a look at what we currently had on CoachRail, which was not awful but it was pretty janky and didn't offer much in terms of practicality for our users.

At this point, I was the lead designer for this project and got a few ideas into a whiteboard then Figma and shared them with my PM to discuss. I presented which new fields and features could be added if we wanted to and how to make the shifting between tools not so prominent, all in a lo-fi design.

Result

Everyone enjoyed it and was pretty confident that tackling the issue like this was the best idea possible considering the constraints we had regarding both development time and how CoachRail's architecture was designed.

This is a trait that appeared all the time at CharterUp, we'd usually push for small updates that wouldn't require a redesign of any major flow, but at the same time address some issues. Band-aiding an issue was the way to go at this part of the project as well.

Feedback

Our PM was pretty confident and shared with the CEO how the solution would work for the day before. The CEO liked the approach but was adamant on his next ask: I want to see the day of, I want it to be ready as soon as possible, so can you start today?

As priorities changed, I needed to step up and work on the Day Of scenario and have another designer deal with the hand-off and some other improvements that were suggested by some users and the CEO.

Flowchart designed by the PM and me to illustrate the journey of the Reps the day before the trip, our actual scenario and some improvements.

Challenges and steering the ship

Juggling two scenarios and responsibilities

01 - Delivery and supervision

The problem

With the day-before design approved, some tweaks and improvements needed to be done to finish this flow, mainly some UI polish, creating a few action flows and exploring how we could have an AI transcription of some calls and surface them there.

As I was needed for the day of part of the project and couldn't be at two places at once, I delegated these improvements and this second delivery phase to another designer. It was my first time calling the shots and setting design priorities for a delivery without any other managerial help.

The solution

I did a hand-off session with the other designer, also left a bunch of comments about product ideas and how we could solve for some issues that were minor but def could help CoachRail and its users. I still had meetings to discuss this project every 15 days and left all channels open to the designer to ask for help.

Overall, it worked great. The day before got its tweaks, we had all scenarios prototyped and presented to the users with great approval.

The hi-fi version of the trip monitoring day before page. We were still exploring where the date selection lives and what the separation between day before and day of would look like.

Challenge 02 - The day of

The problem

This was the really tricky part of the project. The day of was completely new and we needed to come up with the whole flow and interactions for each scenario. At first we focused on nailing the main screen and drill down from it.

At this point the Flightradar24 tracker was the main inspiration for much of what I wanted to do: a bird's-eye view of the continental US that would get progressively closer to a state, a city or a street in which the trip took place.

I was able to sketch something relatively fast and had a US map view and a Bay Area view. Unfortunately, the cluster of shuttles perspective wasn't approved and instead the CEO asked for individual buses. This was a huge point of friction for the experience, because just like we do on FlightRadar, we want to follow specific flights, not all of them. Seeing them might be useful firsthand, but it gets messy if you need to scan through all of them at a glance.

The solution

At this stage, we had a lot of back and forth between business and product. Curating for personal taste in detriment of usability was a hard pill to swallow, especially since I've known that the users would hate using the tool like this.

So I simply let them build this version. Demo to a few folks, see how it'd perform with hundreds of buses on the screen. In the meanwhile I didn't stay idle. I continued creating more flows and diving deeper into the detailed view, while also improving the final version of the global view.

And you know what? It worked like a charm. In a couple of weeks we had the top down decisio to remove the buses and bring back the clusters. When demoing to other stakeholders there was a lot of feedback regarding what could be seem and understood from the home screen.

First of the day-of view, where operators could monitor many trips at one single place.

Results

Placeholder caption for this image.

Final thoughts

This was a pretty challenging project that had a really good result overall. We were able to ship it to a few clients over the next four months and we can see how it works today in the Bay Area.

I've also grown a lot as a designer on this project. Trusted my decisions and didn't back down on the best solution for the problem.

Last I heard, the trip monitoring tool was being expanded to cather not onçy for shuttles but for all buses at CharterUp. I'm really proud of what I've built and how it has impacted thousands of riders all over the US.

What I've learned

Managing, delegating and keeping tabs on someone else's work is challenging, but I had a really good experience with it
Sometines, letting it crash and burn might be the only way someone will listen your design advice. You just need to be prepared to rescue them afte the fall
Dealing with maps was also amazing, I've learned a lot about how the Google Maps API works and how we can tweak it to our benefit