Arvind Shastri

Product designer and software engineer. McMaster Software Engineering, co-founder of Trac.

Hey! I love designing and building products people enjoy. Seeking full-time roles!

Trac Driver

This dash-mounted tablet app allows drivers to broadcast their shuttle's live location, availability, and occupancy in 3 quick taps.

This case study covers the design process for the Trac Driver app. Some technical details and internal information can’t be shared. To learn more about Trac and its shuttle tracking service, visit tracinc.ca.

Overview

Trac Driver is a tablet app that streams live location data from shuttle buses to commuters using the Trac Commuter app.

It’s designed for minimal distraction on dash-mounted tablets. Drivers use it to share their bus’s real-time location, how busy it is and whether it’s in service. It also modernizes passenger counting, replacing paper logs with a simple occupancy control.

Research

To broadcast bus locations, the team considered hardware options like GPS trackers and Bluetooth devices. Tablets were more flexible than traditional trackers: they could send details about the bus alongside its location. Mounted on the dashboard within arm’s reach, a tablet would let drivers quickly set up their bus before starting a “session” that broadcasts it live.

Research showed that dashboard tablets were standard practice for other vehicle tracking services, and modern vehicles already have large dashboard screens, so the interaction would feel familiar.

Talking with drivers, we learned they count passengers by hand every so often, so the shuttle service’s administrators can see how busy it is at different times of day.

After more discussion with stakeholders, we defined the app’s core jobs:

Design process

This design was unusual: a landscape tablet interface used from a driver’s seat. Unlike most apps, built for many screen sizes, this one had to account for the physical setting of someone reaching for a dashboard-mounted screen.

The live location would stream in the background whenever a driver started a session. So the flow split into two parts: a setup, where drivers choose their bus and route, and the session itself, where they update availability and occupancy.

The first quick paper and Figma prototypes focused on separating setup from the session.

With the functionality and hierarchy in place, we tested these prototypes with drivers. They told us small buttons and text were hard to use, and asked for bigger buttons and simpler wording for staff who aren’t tech-savvy.

I hadn’t considered the drivers’ physical limits enough. Seated, they can only reach so far, and since they’re always moving along their route, interactions have to be quick, simple and hard to get wrong. The whitespace looked clean, but it wasted screen space.

The next iteration used larger, bolder elements to make repetitive passenger counting easier, and moved bus status changes into their own component.

High-fidelity prototype, iteration 1Open in Figma

We tested again with drivers and consulted business stakeholders, including the university’s parking office and Attridge Transportation. They pointed out that:

That feedback showed us a chance to simplify the counting process itself. Replacing exact counts with descriptions, from slightly to moderately to very busy, lets drivers judge capacity at a glance and save it with one tap.

The next iteration prioritized large, simple buttons for the repetitive jobs of changing occupancy and availability during a session.

High-fidelity prototype, iteration 2Open in Figma

What drivers liked

Describing occupancy instead of counting worked much better than manual counts. An “on break” status would help them communicate with commuters.

What still got in the way

Selecting a status was confusing; one status at a time would be clearer. The setup screen was crowded, and GPS and connection statuses meant nothing to drivers, since they couldn’t fix them.

We were on the right track. Drivers wanted status selection to be as simple as occupancy, and reminded us that they can’t tinker with the tablet while driving: they can only act on information they understand.

To simplify setup, we tried six-digit bus numbers and QR codes to identify sessions. In practice, buses and drivers were swapped around constantly, and drivers cared most about starting a session quickly, whatever the bus or tablet. The idea only confused them more, so we dropped it and removed bus numbers entirely, since they did nothing for commuters either.

An iteration with bus numbers and QR codes
Bus numbers and QR codes

In the end, setup split into a home screen and route selection, trimmed to the essentials. Without bus numbers, drivers can start a session in three taps. GPS statuses and live error messages were removed, replaced by pop-up messages only when needed. On-break and going-on-break statuses were added so commuters can see what’s happening.

Final Trac Driver screens

Final result

The final app has a consistent interface and hierarchy. The welcome screen invites new and returning drivers to start a session, with a tutorial one tap away. Route selection shows a preview image for each route in a scrolling panel, which can be enlarged. The session screen splits into two clear panes: occupancy on the left, availability on the right. When the bus isn’t in service, the occupancy pane greys out behind a lock. A dark theme helps at night.

The design leans on minimal text and clear icons so drivers can start a session quickly. It turns manual passenger counting into one-tap occupancy updates.

Trac Driver runs on six shuttle buses across five routes at McMaster University, helping hundreds of commuters find their nearest bus every day.

Projects

Experience

Contact

arvind.shastri@outlook.com · LinkedIn ·GitHub · Résumé (PDF)