Case study
Driver dashboard
Bus drivers don't use software in a quiet office. They use it in a cab, in sunlight, with the bus moving, a timetable running and passengers waiting. The driver HMI is where the journey starts, and the driver has to be able to read it at a glance.
What it does
The onboard computer is the brain of the bus. The driver HMI is the touchscreen on top of it. Drivers use it to take over duty, log in, pick a service, follow the route, handle ticketing, count passengers, request inspections and stay in touch with operations.
It's a working tool. Drivers use it at the start of every shift, at every stop, and whenever operations needs something from them. It carries a lot of state, and the driver can't stop to study it.
Why it's hard
The screen is small, the cab is noisy and the driver is watching the road. Every action has to be obvious under time pressure, and every screen has to work with the bus's hardware and the platform's data model.
So for every screen I asked one question: what does the driver need right now? That gets the space. Everything else stays reachable but out of the way.
A driver gives the screen a few seconds, tops.
How I built it
I built the driver-facing screens and wired them to the onboard services. The screen follows the state of the journey. It shows the current journey, the next stop, the departure status and any messages from operations.
Big touch targets, high contrast and the same bottom navigation everywhere, so the driver never hunts for a button. The things that matter most get the most space: where the bus is, what comes next and whether it's cleared to leave.
What I built
- Driver login and service selection.
- Journey and stop screens with a departure countdown and a "departure on order" state.
- Entry points for ticketing and passenger counting.
- Inspection requests and messages from operations.
- A touch-first layout for the cab display.
Choices I made
Readable at a glance
The next stop and the departure time are the anchors. Everything else is reachable, but it doesn't fight them for attention.
Built for one hand
The main buttons sit at the bottom of the screen, within reach. I assumed the driver could be standing, sitting or leaning across the cab. Nobody has a mouse in there.
Follow the journey state
The UI follows the journey state machine. Each phase of the journey uses the same visual language, so the driver doesn't have to relearn the screen when the state changes.
Expect things to go wrong
On a bus, data arrives late, peripherals go missing and state is sometimes only half there. I made sure the driver still gets a usable picture when that happens.
The screens
The result
Everything the driver needs is on one screen: who's driving, which service is running, where the bus is, what's next and what operations wants.
It's the kind of interface work I like most. Screens that sit on top of a real system and get used by someone with a bus to drive.