Campus Transit that Helps SCAD Students Recover When Plans Change
A system-level redesign of SCAD's campus shuttle system, from route discovery down to the moment a bus stops running mid-commute. Bee Line replaces a confusing, one-size-fits-all route list with a location-aware home screen and a built-in recovery path for every disruption.
Students were used to being “locked” in a dead end if an emergency came up; but now, Bee Line turns it into a guided decision.
When the shuttle stops unexpectedly, what happens next is where the two systems diverge.
Bee Line is a second-iteration redesign of SCAD's TransLoc-based shuttle system. After an earlier pass only surfaced surface-level issues, I formed a new team under my professor's guidance to dig into the real pain points: route planning, real-time visibility, and recovery when a route breaks down mid-trip. We worked it as a service design studio, using desktop walkthroughs, conversational prototyping, and iterative usability testing with fellow students.
Students struggled not only to start their journey, but also to recover when the journey didn't go as planned.
SCAD's campus is spread across downtown Savannah, so students shuttle constantly between studio buildings, dorms, and dining halls that can sit a mile or more apart. The existing app doesn't help much: bus info is hard to parse at a glance, nearby stops aren't obvious, and when a route goes down mid-trip, there's no one to ask and nothing telling students what to do next.
Look for another bus that still reaches their destination
Call an Uber or Lyft
Ask around if a nearby classmate can give them a ride
Walk
We simulate student and shuttle interactions, mapping out various scenarios to identify pain points. By analyzing the sequence of events, we traced issues back to their underlying system causes, allowing us to pinpoint areas for improvement in the shuttle experience.
We then applied conversational prototyping, treating the shuttle system as a virtual consultant to engage users in natural dialogues. By simulating real-time interactions, we gained deeper insights into how students express their needs, make decisions, and navigate the shuttle system. This approach allowed us to uncover pain points more organically and refine our design to better align with user expectations.
“How to Choose the Line?”
A step-by-step trace of the as-is TransLoc flow, each screen paired with real feedback, its pain point, and the design opportunity it revealed.
“TBH, I use TransLoc to do the same operation every day, and I can’t directly check which route I use most frequently.”
“There are too many overlapping routes. I can’t recognize buildings. I need to click on them one by one.”
The information of the map is cluttered.
Quick action — preference line.
“I want to visit an unfamiliar building, but I often can’t find the correct building name here, and I can’t tell if it is a SCAD building.”
“Every time I search for a destination, no relevant line types are displayed.”
The lack of key information in the search box.
Quick action — preference line.
“When I go to an unfamiliar teaching building, I don’t know which line is the fastest. In other words, I can take some time to walk to the second closest station to my home, but I often have to spend a long time to compare and contrast which one is the most convenient and does not require me to transfer to other routes.”
“After opening Green, I found that there was no bus at all. This line was unavailable and I didn’t know why.”
Recommendation function for routes.
“The destination I just searched for is not displayed on the stops list, which may cause me to miss it. The nearest stop to the destination should be displayed.”
“I need to repeat the operation many times and check every line, because sometimes I need to transfer. This is the most troublesome thing for me. I need the fastest route without having to walk too long or wait too long.”
“Sometimes, even if I set an alarm, I will still miss the bus. I hope I can be notified by SMS or other platforms, at least so that I can exit the app and hear that the school bus is about to arrive, so that at least I can speed up my walking speed.”
The alarm’s reliability is too low.
Alarm’s message linkage.
Overlapping routes on one map make lines and buildings hard to tell apart, with no clear landmarks or simplified visualization.
Users can't easily tell which line is fastest or closest, so they compare routes by hand, and destination stops aren't always shown.
Searching for destinations and comparing routes takes repeated effort, with no streamlined way to do these common tasks.
Alarms don't reliably get students' attention, so buses still get missed even with a reminder set.
help students find campus buses faster?
help students continue their journey, even when the expected route fails?
“If my bus is full, my whole plan falls apart. Buses on my line can be 30 minutes apart, so missing one means I'm late no matter what I do.”
That feedback sent us through three directions before we landed on the one that shipped.
Our first instinct was to let students reserve a specific bus, departure time, and seat ahead of time, so a full bus would never catch them off guard.
×
Most students were genuinely fine standing for a short ride. Reserving a seat solved a problem almost nobody actually had, so it wasn't worth the added complexity.
Instead of a faster bus, how do we get students to where they're going?
The deeper we looked, the more disruptions we found, so the real question became how to rescue students from an emergency. And when we asked why students were “running” for the bus at all, the answer was almost always the same: they didn't want to be marked absent.
So we designed a way to connect the bus system straight to the classroom: if a student's bus hit a delay, the professor for that class would be notified automatically, so the absence wouldn't get marked.
×
This one got pushed back harder, for two reasons: professors have no way to tell whether a student left late on their own or genuinely got squeezed by back-to-back classes and a tight transfer, and professors already use their own judgment, if a bus really did cause the delay, they weren't marking it absent to begin with.
Our third direction focused on what students actually needed: not proof for a professor, but a way to keep moving. When a route goes down, the system pushes ranked alternative routes based on the student's destination, so they can pick one and get going again.
Working with a professor who could push back felt like reporting to a lead: I had to resolve the feedback, not overrule it. Two rejected directions later, that back-and-forth is what got us to the one that actually worked.
Route selection is organized around three bars: 1) View All the Bus Lines, 2) Surrounding Route Display, and 3) Destination Route Planner, and current-location plus destination always highlighted on the map with substitution recommendation when emergency comes.
The hardest tension in this redesign was informational, not visual: showing enough real-time detail without recreating the clutter that made the original map unreadable. We resolved it by pushing detail down a level.
Putting each version of the prototype in front of students and annotating exactly where it broke down before moving to the next iteration.
“I want to find my current bus lines from the home screen and figure out which building I need to get to — there’s no way to enter a destination yet.”
“I want to set my destination, pick a line from the Recommended Lines list, and check the stop-by-stop view for my route.”
“My bus just stopped running mid-trip — I want to understand what happened and find another way to get where I’m going.”
A location-aware home screen that shows the relevant lines automatically, cutting out the repetitive search-and-compare loop students described in research.
SCAD Building badges and clearer current-location / destination markers, resolving the building-identification confusion that was the top-cited pain point.
A built-in emergency recovery flow, turning a dead-end service disruption into an alert with a ranked, ready-to-pick alternative route.
A validated design, refined against real usability-test feedback across three task scenarios before final hand-off.
The student opens to a home screen that already shows their usual lines, picks one and tracks it stop by stop, then, when that bus stops running mid-trip, they get an alert with a ready substitute line, all without leaving the flow or starting over.
Automatically showing lines around the user
Clicking to see all serving lines
Clicking location to see all bus lines around
Choosing a certain line
Looking through all stops of the line
Searching to see surrounding bus lines
While selecting the destination and bus line, click to see the tracing stops
The user receives a pop-up if an emergency, such as the expected bus line stopping, occurs
The system provides substitute choices for users to select another line
The alert only appears once the disruption has already happened, then recommends an alternative line.
An early warning fires ahead of time, so students can start planning before the disruption occurs.
Before handoff, we put the finished prototype in front of 4 students for one last round of live testing to confirm the redesign actually worked.
“This is so much more convenient than my school's current app.”
Under the guidance of professor and in collaboration with team, I learned how to look beyond surface requests and solve the root problem. By shifting our brief from ‘seat selection’ to route discovery and emergency substitution, we addressed students’ true commuting friction. Utilizing interactive research methods helped us trace frustration back to system-level causes, while iterative team collaboration ensured the final solution was both user-centered and feasible to ship.
