Fig 1.0: Proposed redesign of the TTC bus Passenger Information Display (PID)
At a glance
- Field observation across 6 routes revealed riders pressing the stop button multiple times, not from impatience, but because visual confirmation disappears into a rotating display before they can verify it
- The proposed solution is a persistent badge that remains visible outside the content rotation: the only software-only approach that closes the persistence gap without disrupting route information
- The proposal was well received by TTC’s passenger information team; they were already aware of this issue and had independently developed a new display design grounded in a unified design system aligned with Metrolinx
A persistence problem with stop request feedback
Research revealed that the stop request feedback has a core problem: the confirmation cycles away before riders can verify it.
Video 1.0: The persistence issue captured. Stop request confirmation disappears into the display rotation
Confirmation disappears into rotation
The display cycles through 5 information types every ~5 seconds. When a stop is requested, the “Stop Requested” confirmation is added to the rotation queue and cycles alongside all other content.
Riders who missed hearing the chime had to stay glued to the screen for the full rotation cycle to visually confirm their stop was registered. This demands sustained attention in an environment where glances are typically under 3 seconds.
“I saw it say stop requested for a second, then it switched to something else. I'm not sure if the stop request is still active.”
— Rider during interview, 939 Finch Express
Rider presses stop button
Physical press registers with the system
Auditory chime plays
Confirms press was registered
Visual confirmation appears
Display shows "Stop Requested", visible for ~5 seconds
Display cycles to other content
Confirmation disappears; rotation resumes (next stop, current time, operator id etc.)
"Did it work?" Rider glancing at screen sees no confirmation. Uncertainty window: the re-press risk is highest here.
"Stop Requested" re-appears
Rotation brings it back, but rider may have already re-pressed during the 10–15s gap
Non-persistent confirmation fails under glance-based conditions
Riders glance at displays for a few seconds at most. When the “Stop Requested” message cycles away into the rotation, riders who look up at any other moment see no confirmation at all. This is what triggers the repeat press.
More critically: a rider who missed the auditory chime has no reliable way to verify their stop was registered. Visual confirmation that persists is not an enhancement. It's parity.
How I structured the research
Field observation was chosen over surveys or analytics because the behaviour under investigation (repeat button presses) is contextual. It only makes sense when you see where the rider is looking, how long they wait, and what the display is showing at that moment.
6 routes over 3 weeks
- Routes: 29 Dufferin, 939 Finch Express, 54 Lawrence East, 95 York Mills, 102 Markham Road, 133 Neilson
- Peak (7–9 AM, 5–7 PM) and off-peak hours
- Tracked button press frequency, gaze direction, and display state
- ~18 hours of in-vehicle observation
8 riders, in-context
- Recruited riders observed pressing the button, then interviewed after leaving the bus
- Short semi-structured interviews (3–5 min)
- Focused on: certainty of registration, what cues they used, and what would help
- Themes synthesized through affinity mapping
This research is directional, not statistically representative
8 interviews and 6 routes are sufficient to identify a behavioural pattern and form a design hypothesis, but not to generalize across the entire TTC network. The pilot evaluation logic later in this study is designed to generate the statistical evidence this exploratory phase intentionally did not.
Why other approaches fall short
Before landing on the persistent badge, I evaluated three other software-only approaches against the core requirement: a rider must be able to confirm their stop is registered in a single glance, at any point after pressing the button.
Larger / brighter "Stop Requested" text
Increasing the size or contrast of the existing message addresses salience, not persistence. A larger message that disappears in 5 seconds still can't be verified during a 25-second rotation cycle.
Extended rotation dwell time
Keeping "Stop Requested" on screen for longer (e.g., 10 seconds instead of 5) would still cycle away. Any approach that enters the rotation queue eventually disappears. Additionally, extending dwell time delays route and stop information that riders also need.
Full-screen takeover on button press
Replacing the entire display with "STOP REQUESTED" for 5–10 seconds guarantees visibility but blocks all other information. Confirmation should be additive, not substitutive.
Each rejected approach fails for the same structural reason: it treats “Stop Requested” as content to be displayed rather than a persistent state to be communicated.
Persistent badge outside the rotation
A dedicated zone outside the content rotation that remains visible until the bus reaches the stop: the only software-only approach that enables glance-resolvable confirmation without disrupting route information.
The proposed design includes two major additions beyond the core fix: transfer connection badges at each stop, and a destination arrival time. Further UX improvements are detailed in the breakdown below.
Fig 3.0: Proposed persistent badge. Remains visible outside the rotation until the stop is reached
Current and Proposed
Fig 4.0: Drag to compare the current rotating confirmation vs. the proposed persistent badge
Critical Assumptions
- Riders glance at display within seconds of pressing button
- Repeat presses are driven by uncertainty, not impatience
- Badge concept is understood without explanation
- Display firmware supports dynamic zone allocation
- Persistent badge won't create alert fatigue over time
- Badge remains legible under all lighting conditions
What would invalidate this model
If repeat press behavior persists after badge deployment, the problem is not visibility but deeper trust calibration; riders may not trust any system feedback regardless of persistence.
Known risks and edge cases
- Visual crowding during high-density information states
- Badge habituation risk over time reducing attention value
Why the proposed design works better
The redesign applies established UX principles to reduce cognitive load and improve at-a-glance comprehension for riders in a moving vehicle.
Persistence over rotation
- "Stop Requested" displays as the next rotation item, then cycles back with all other content
- Riders must watch and wait for it to reappear
- Forces recall of whether they saw it
- Persistent badge stays visible from the moment the button is pressed
- Rider can verify in a single glance at any point
- Relies on recognition instead of memory
Visual hierarchy
- All content competes at equal weight inside a single cycling header
- Stop name, time, and "Stop Requested" share the same visual treatment
- Three distinct zones (primary, upcoming, route) use size, weight, and spatial separation
- Clear reading order where the next stop is always the largest element on screen
Signal-to-noise ratio
- Per-stop "Estimate" column shows times for each upcoming stop
- The extra column competes for horizontal space with stop names, reducing legibility at distance
- Per-stop estimates removed; freed horizontal space used for larger stop names and transfer connection badges
- The destination arrival time becomes the only remaining time value on screen
- Riders can spot transfer options at a glance without prior route knowledge
Concept Validation
Four commuters reviewed current and proposed mockups shown on an iPad, providing an early read on whether the redesign resolved the core confusion.
Riders understood the persistent badge without explanation; the always-visible confirmation resolved the doubt that drove repeat presses
On-vehicle behavior under real lighting and motion; long-term habituation effects; interaction with service alerts
Sufficient confidence to propose a controlled pilot, not full fleet rollout; pilot design must address remaining uncertainties
Considerations for engineering
- Transfer connection data: TTC route stops data exists, but can the on-vehicle display system store or fetch a dataset of that size without performance constraints?
- Real-time GTFS-RT feed: can the on-vehicle system consume a live trip update feed to resolve destination ETA, and what is the fallback if the feed drops?
Press STOP to compare how each display responds
Fig 3.1: Press STOP to compare — current display cycles “STOP REQUESTED” with other content; proposed keeps it persistently visible
Where this landed
In late 2023, after publishing this case study, TTCriders.ca (opens in new tab) connected me with TTC's passenger information display team. In a 45-minute meeting, the proposal was well received. The team shared that they had independently identified the same issues and were already developing a new display design grounded in a unified design system aligned with Metrolinx, with incremental rollout planned.
Pilot evaluation logic
Additional opportunity from research
Rider interviews surfaced a need beyond stop confirmation. This was consciously deprioritized to maintain focus on the confirmation problem. It represents potential future work, contingent on validating the core solution first.
Fig 5.0: Proposed display mockups — transfer connections and real-time subway alerts
Real-time subway service alerts
Surface subway disruptions on bus displays for connecting routes. Riders learn about delays before arriving, with time to adjust plans.
Make informed decisions while still on the bus.
Persistent on-screen alerts are essential for deaf and hard-of-hearing riders who can't rely on verbal announcements.
Requires PID access to TTC's service alerts API. Surfacing subway alerts alongside stop confirmation risks overwhelming passengers with competing information.
What I learned
User behavior
Repeat button presses weren't user error; they were a rational response to unclear feedback.
Scope constraint
The constraint of "software only" focused the solutions on what was actually achievable.
What I'd do differently
Validate the software assumption earlier
Engaging engineering contacts before finalizing the proposal would have strengthened feasibility claims
Frame system-level impact upfront
Leading with how display changes affect the entire network, not just individual riders, would better resonate with stakeholders
Test with more accessibility participants
A larger sample would validate the accessibility value propositions more rigorously
The bigger picture
Every pixel is an opportunity
Every pixel on a transit display is an opportunity to reduce rider uncertainty. When hardware investments are already in place, thoughtful UX refinements can unlock significant value at minimal cost.