At the stop
Physical route signage. A map built from zero, because Seattle stops have none.
Case Study
Seattle bus riders hit a different failure at every stage of a trip. Four prototypes layer physical and digital wayfinding so no stage stands alone.
Timeline
10 weeks
Role
Product Designer, Researcher
Team
2 Product Designers
2 Researchers
Context
MHCI+D program studio
TL;DR
Seattle's bus stops have text lists and no maps, and in our benchmark it was the only city where navigating without a phone was effectively impossible. We designed four layers, one for each stage of a trip, so no single failure strands the rider.
What I Did + My Impact
Led the physical wayfinding for a city that had none
Seattle stops are text lists. In our benchmark, it was the only city with no map at the stop. I designed the map from zero and tested what geographic information riders need without a phone.
Redirected the project from “no phones” to “when the phone fails”
I brought the GPS research, then argued we should work with how riders already navigate — and keep them confident they are on track.
Ran testing across all four prototypes and surfaced the connecting pattern
Designs that broke from conventions riders already knew increased uncertainty, not as a preference but as a stress response.
HIGHLIGHTS
Four prototypes, each targeting a validated failure mode, designed as layers rather than alternatives. Any one of them can fail without stranding the rider.
Physical route signage. A map built from zero, because Seattle stops have none.
Arrival time accuracy indicator in OneBusAway.
On-bus LED display. Consistent stop-request feedback across a fleet that currently handles it differently on every bus.
Bus travel widget. Persistent status on the trip, so riders don't have to keep reopening the app to feel on track.
Problem
The project started from research I brought to the team: habitual GPS use is associated with a measurable decline in spatial memory (Dahmani & Bohbot, 2020). Our first direction was getting riders off their phones. That was the wrong problem for a ten-week studio, since riders already navigate by phone. We shifted to a when-the-phone-fails question, and then to the anxiety of not knowing you're on track. Resilience meant layers that cover for each other.
Seattle's stops have no route maps, no geographic context and no direction indicators. Seattle was the only city in our benchmark where navigating without a phone was effectively impossible.
The most exposed riders are new residents, tourists, and anyone without a smartphone, battery or signal.
"Yesterday my phone was at 12%. [I was] anxious. I don't know this neighborhood, I don't know how many stops I need to go." - Interview participant, 2025
INSERT STAT BAND HERE
Task
Map where Seattle's wayfinding fails, understand why, and identify which interventions would most improve rider confidence and independence. Entering prototyping, I owned the signage and one question: what does a bus stop map need to show for a rider to orient without a phone?
Research
Literature review, competitive analysis, government data
Set the spatial-memory premise and the benchmark gap
8 semi-structured interviews
Phone-checking is anxious, not habitual

Independent observation at transit hubs
The critical failure happens before boarding, not on the bus
Interviews surface what riders remember. Observation shows what they do, including checking their phone every thirty seconds on a route they've taken a hundred times. Both pointed to the same thing: riders check because nothing else confirms they're in the right place.
Resilience
No dependable non-digital fallback when devices fail
Anxiety Reduction
Navigation itself as a source of stress
Trust
Riders have stopped believing arrival times due to inaccuracy
"The signs are so frequently broken... Even when signs work, they typically are not accurate." - Interview participant, 2025
Process
Two questions decided what advanced: does it address a validated failure mode, and can we test it at low fidelity and still learn something real? Four concepts made the cut, and I took the physical signage.
I focused on the minute before boarding: finding the right stop, confirming the route, knowing which way you're facing. One participant boarded the wrong bus at the right stop. Google Maps said her bus was a minute away, and the LED display kept cycling between the route number and "fare required."
"…I only see the 'fares required' and I'm like, you know what? Benefit of the doubt, this is probably my bus because it [Google Maps] said my bus is coming in a minute, so I get on it. And then it [once I'm on], like, turns or something, takes a completely different route." - Interview participant, 2025
That's a systems failure, not user error. The LED display, the stop signage and the navigation app each failed to give her the one thing she needed.
Neighborhoods here are defined by water: Lake Union, Puget Sound, Lake Washington. Riders recognize those spatially without knowing an address, so I built the signage around them.
Testing + Takeaways
Color needed a legend riders didn't have. Geographic information worked and the encoding didn't. Color-coded zones without text asked a rider with a low battery in an unfamiliar neighborhood to learn a legend first. Text labels with geographic landmarks read immediately in testing, but they didn't go through another iteration, so they stand as the recommended direction, not a tested result.
Low fidelity limits the claim. It showed the color system as built didn't work. It couldn't show whether better-executed color would have worked or whether color is the wrong encoding here.
"I like how this map gives more context with the water." - signage testing participant, 2025
"I would still need my phone to navigate with this map though." - signage testing participant, 2025
Not a rejection. A diagnosis. Geographic context was the right ingredient; the visual language wasn't yet legible enough to stand alone.
Because I tested across all four prototypes, I could see what no single session showed: riders respond to familiar conventions and reject unfamiliar ones, as a stress response rather than a preference. The LED display made it clearest. Stop names are mostly cross-streets that don't fit the screen, and buses handle stop-request feedback differently (a light, a separate screen, or an overwritten stop name), so every bus is a new guessing game at the moment a rider needs confirmation.
What is the difference between estimated and scheduled? Aren't all times just estimates?" — Evaluative testing participant, 2025
Clarity isn't only visual. That's a wording problem, not a layout problem.
Final Product
Four prototypes, each targeting a validated failure mode, designed as layers rather than alternatives. Any one of them can fail without stranding the rider.
At the stop: Physical Route Signage (my design)
A map built around geographic landmarks, so a rider can orient with no phone. Three variants tested; text labels with landmarks are the recommended direction. Seattle stops had no map to improve on, so the starting point was zero.
While waiting: Arrival Time Accuracy Indicator
A redesigned label in OneBusAway showing how much confidence an arrival estimate deserves. The icon version confused 9 of 9 participants and was set aside; text labels were understood by 6 of 9 when the wording was specific.
Onboard: In-Bus LED Display
A standardized display with consistent stop-request feedback. The problem was never a missing confirmation state; it's that every bus handles it differently, so riders can't build a mental model that survives the next bus.
The whole ride: Bus Travel Widget (my concept)
An iOS widget showing trip status, so riders don't have to keep reopening the app to feel on track. It came from one observation: riders reopen the app not because they need new information, but because closing it means losing visibility.
Geographic context is load-bearing.
Riders need spatial anchors (landmarks, neighborhoods, water) to place themselves. Signage without them isn't a fallback; it's a list.
Familiar format beats added complexity.
Under stress, riders disengage from new conventions. The color system, the icons and the inconsistent LED display all raised uncertainty.
Redundancy is the system, not a hedge.
The widget helps until the battery dies, the LED display until the bus is rerouted, the signage until it's faded. Layers that cover each other are what make it resilient.
These hold beyond Seattle: anchor to context people already have, respect the format they already know, and never let one point of failure break the experience.
Reflection
Seattle's gap had been framed as a technology problem: better apps, more accurate data, real-time displays. The research showed the foundation was missing. A rider whose phone is dead needs something to look at. On future projects, before I design anything that depends on a battery, a signal or an app, I'll ask what the person has left when it fails.
Testing across all four prototypes showed me that findings look isolated one at a time and only show their pattern from above. Next time I'll plan evaluative coverage across the whole system from the start, and decide up front which questions a low-fidelity prototype can answer, so a question like the color system doesn't stay open.
Build and test the recommended direction
Higher fidelity would settle whether color was the wrong encoding all along.
Test at a real stop
Build the first-contact experience testing identified as the critical missing piece
Find the "I'd still need my phone" ceiling
Can physical signage ever stand alone, or does it always supplement digital tools?