public transit · FIELD RESEARCH · DESIGN PROPOSAL

Improving the TTC Bus Passenger Info Display (PID) with software only changes

Stop request confirmation gets buried in the display rotation. Field research with transit riders led to a software-only redesign proposal.

Wide-angle photo of new TTC bus interior showing the LCD passenger information display mounted above the front windows

Fig 1.0: Proposed redesign of the TTC bus Passenger Information Display (PID)

Role Research & Design (Solo)
Duration 6 weeks (2023, June - July)
Methods Field Observation, Interviews
Status Design Proposal
Overview

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
Findings

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

Identified Issue

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
Event Timeline
0.0s
Rider presses stop button
Physical press registers with the system
0.1s
Auditory chime plays
Confirms press was registered
~5s
Visual confirmation appears
Display shows “Stop Requested”, visible for ~5 seconds
~10s
Display cycles to other content
Confirmation disappears; rotation resumes (next stop, current time, operator id etc.)
10–15s
“Did it work?” Rider glancing at screen sees no confirmation. Uncertainty window: the re-press risk is highest here.
~15s
“Stop Requested” re-appears
Rotation brings it back, but rider may have already re-pressed during the 10–15s gap
Core Finding

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.

Research Approach

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.

Field Observation

6 routes over 3 weeks

  • Routes selected for ridership volume and geographic spread: 29 Dufferin, 939 Finch Express, 54 Lawrence East, 95 York Mills, 102 Markham Road, 133 Neilson
  • Observed during peak (7–9 AM, 5–7 PM) and off-peak hours
  • Tracked button press frequency, rider gaze direction, and display state at moment of press
  • Total of ~18 hours of in-vehicle observation
Rider Interviews

8 riders, in-context

  • Recruited riders who had just pressed the button (observed the behaviour first, then asked about it)
  • Short semi-structured interviews (3–5 minutes) conducted after leaving the bus
  • Focused on: what they were looking for, whether they felt certain their stop was registered, and what would help
  • Themes synthesized through affinity mapping
Methodological Note

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.

Alternatives Considered

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.

Rejected

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. Riders can see it when it's visible, but the problem is they can't find it when they look.

Rejected

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.

Rejected

Full-screen takeover on button press

Replacing the entire display with "STOP REQUESTED" for 5–10 seconds guarantees visibility but blocks all other information. A rider looking for their next stop or transfer connection loses access to wayfinding data at the moment they need it most. 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.

The Solution

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 below 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.

Proposed PID display: persistent badge always visible
Fig 3.0: Proposed persistent badge. Remains visible outside the rotation until the stop is reached

Critical Assumptions

Tested / Observed
  • Riders glance at display within seconds of pressing button
  • Repeat presses are driven by uncertainty, not impatience
  • Badge concept is understood without explanation (validated in informal comparison)
Untested / Hypothesized
  • Display firmware supports dynamic zone allocation (requires engineering confirmation)
  • Persistent badge won't create alert fatigue over time (requires longitudinal study)
  • Badge remains legible under all lighting conditions (requires on-vehicle testing)
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

Current and Proposed

Current
Proposed

Fig 4.0: Drag to compare proposed persistent badge vs. current rotating confirmation

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 Core Fix
Current
  • "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
Proposed
  • 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
Current
  • All content competes at equal weight inside a single cycling header
  • Stop name, time, and "Stop Requested" share the same visual treatment
Proposed
  • 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
Current
  • Per-stop "Estimate" column shows times for each upcoming stop
  • The extra column competes for horizontal space with stop names, reducing legibility at distance
Proposed
  • Per-stop estimates removed; freed horizontal space used for larger stop names and transfer connection badges at applicable stops, shifting the display from a passive progress indicator to an active wayfinding tool
  • With the per-stop column gone, the destination arrival time becomes the only remaining time value on screen: the one trip-level number that answers whether riders will get there on time
  • Riders can spot transfer options at a glance without prior route knowledge

Rotate for better experience The interactive display mockup is best viewed in landscape orientation

Interactive Prototype Press STOP to compare how each display responds
Stop Requested
Current
To 939c Finch Express to Morningside Heights
Upcoming Stops Estimate
Warden Ave Birchmount Rd Kennedy Rd

Welcome
Aboard

After pressing STOP, the "STOP REQUESTED" enters the rotation queue and cycles with other content rather than staying visible.
Proposed
Next Stop
OP ID: 85700

Warden Ave

68 968
Birchmount Rd
17
Kennedy Rd
43A 943
939C Finch Express to Morningside Heights
Arrival: ~18 min
After pressing STOP, the "STOP REQUESTED" badge stays persistently visible outside the rotation.

Fig 3.1: Interactive prototype — Press the STOP button to compare how each display responds. Current cycles "STOP REQUESTED" with other content; Proposed keeps it persistently visible on screen

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.

Uncertainty Reduced

Riders understood the persistent badge without explanation; the always-visible confirmation resolved the doubt that drove repeat presses

Uncertainty Remaining

On-vehicle behavior under real lighting and motion; long-term habituation effects; interaction with service alerts

Decision This Enables

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?
Outcome

Where this landed

In late 2023, after publishing this case study, TTCriders.ca 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

Baseline signal Repeat press frequency on control routes (current state)
Expected change Directional reduction in repeat presses on pilot routes
Observation window 2–4 weeks post-deployment to allow behavioral adjustment
Confounds to monitor Route type (express vs local), rider familiarity
Failure signal No measurable change in repeat behavior
Deployment scope 5–10 buses on high-frequency routes for A/B comparison
Beyond the Core Problem

Additional opportunity from research

Rider interviews surfaced a need beyond stop confirmation. This was consciously deprioritized to maintain focus on the confirmation problem, the most tractable issue with clearest evidence. It represents potential future work, contingent on validating the core solution first.

Future Opportunity
Proposed display mockups showing transfer connections and subway alerts

Fig 5.0: Proposed display mockups showing 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.

Rider value: Make informed decisions while still on the bus.
Accessibility value: Persistent on-screen alerts are essential for deaf and hard-of-hearing riders who can't rely on verbal announcements.
Engineering consideration: Requires PID access to TTC's service alerts API. Surfacing subway alerts alongside stop confirmation risks overwhelming passengers with competing information.
Reflection

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.