Google-mentored capstone, UW-Madison Capstone: Fall 2024

A fleet operations dashboard for autonomous cabs

Designing for a job nobody has yet. Autonomous fleets are leaving pilot, and operator tooling is still three browser tabs and a spreadsheet. I designed and built the command centre.

Design engineer August–December 2024
10 fleet operator interviews
3 usability walkthroughs
1 card sort for alert priority
Research counts; the fleet itself was simulated.
Mine
  • User research
  • Interaction design
  • UI design
  • Front end
  • Usability testing
Shared
  • Product scopewith PM
  • Design reviewswith Google mentors
Not mine
  • Fleet simulation
  • Back end
The only designer on the team.

The situation

Constant data. No way to read any of it.

Autonomous cabs stream telemetry nonstop into tools built for human-driven fleets, where the car reports to a person and the person reports to you.

6pm · rush hour200 cabs on the road
Simulated

Research

Nobody has this job yet. So who do you interview?

We had no access to Waymo or Zoox, so I researched the parts of the job that already exist: monitoring, dispatching and maintenance.

Autonomy changes what raises an alert, not what triaging twelve at once feels like.

“I open 3 tabs just to check location”
“Battery status isn't visible until it's too late”
“Feels like we're flying blind.”

Basic questions took 3 to 6 tools.

The idea

One surface. Every alert arrives ready to act on.

Three questions, three screens. Each screen answers exactly one:

  • Fleet Overview. Is my fleet running smoothly right now?
  • Alert panel and vehicle modal. What needs attention, and what can I do about it?
  • Maintenance board. Where are we in resolving it?

A page navigation costs the operator their context: the map state, the other eleven alerts, the thing they were half way through. In an ops-critical interface that context is the work.

The modal keeps the fleet visible behind the decision, which is why triage is two clicks rather than a round trip.

Wireframe 1
Layout before visuals: every region has to answer a question.

The design

Three tab switches. One flow removed each of them.

One flow for each research finding.

Maintenance without spreadsheets. A board moving each issue from open to resolved, beside live vehicle health.

Alerts that are instantly actionable. Each alert opens its vehicle, with "send to charging" one click away.

Routes with the evidence attached. Current versus optimal route time, from live and historical traffic.

Fleet Overview
Availability, live GPS and alerts in one view. Figures are simulated, not measured.

Principles

Read fast, move faster. The three rules the screen is built on.

Most actions take one or two clicks. Anything that took three got redesigned.

Across three tools
  1. Alerts: Notice
  2. Vehicle: Find the vehicle
  3. Ride: Check the context
  4. Vehicle: Act
  5. Sheet: Log itOften never
On one surface
  1. Console: Alert fires
  2. Console: Open the vehicle
  3. Console: Act and closeTicket writes itself
Runs on its own
One battery alert, before and after.

Reflection

Given real access: the next three things I would build.

This ran against a simulation, so every speed claim here is a hypothesis until it meets a real fleet.

Next I'd test ten times the vehicles, where the alert list becomes noise, and whether an AI co-pilot helps or just adds another voice.

Role
Design Engineer
Team
Design Engineer (Me), 4 Engineers, 1 Product Manager, 2 Google Mentors
Timeline
August–December 2024
Tools
Figma, React, Copilot, v0