Arrowhead Transit
Intranet
ROLE
Lead Product Designer
TOOLS
Figma, Whimsical, Notion, Airtable
Arrowhead Transit books more than 100 healthcare transport rides a day — every one of them scheduled through a single Access database file, copied by hand between desks. I replaced it with a live dispatch platform dispatchers, drivers, and billing could all see at once.
Exhibit A — the entire operation, in one Access file. No login. No history. No way to work outside the office.
The Problem
Three ways the system worked against the people who depended on it
One file, one desk
The entire schedule lived in a local Access database — copied by hand between computers, with no login and no way to work outside the office.
Every leg, typed twice
Dispatchers entered each ride manually, one leg at a time. The workflow was slow enough that planning more than two or three days out was rare.
Dispatch by phone call
With no online platform, every schedule change meant a phone call — or a paper form a driver filled out on the road and handed in later.
Arrowhead Transit’s core job is getting healthcare patients to appointments. A scheduling system only one person could see at a time wasn’t just inconvenient — it was risk sitting in a spreadsheet.
So I rebuilt the system of record — as a platform everyone could see at once.
So I rebuilt the system of record — as a platform everyone could see at once.
The Decisions
Three calls that shaped how it actually got used
The brief was simple — replace the database, cut manual entry, connect drivers and dispatch. Getting there took a few specific, and occasionally uncomfortable, calls.
Decision
Read-only, except where it mattered
Drivers needed live visibility into logs, routes, and trip details — but editing rights on that data belonged to dispatch. I scoped the driver view to read-only, with one exception: odometer and time entries on billing, the two fields only a driver on-site could actually verify.
From the sitemap — permission boundaries by role
Decision
One queue for every outside referral
Ride referrals were arriving from multiple insurance and referral sources — Laserfiche, Novus — entirely outside the old system. Dispatchers were hunting them down by hand. I gave every external referral one landing point: an Incoming Trips queue, visible the moment a request comes in.
Queue management UI overview
Constraint
Borrowed the design system, on purpose
This ran on a nonprofit's timeline, not a greenfield brand budget. Instead of building a bespoke visual system, I adapted my studio's existing framework to Arrowhead Transit's brand — trading a fully custom look for the weeks that went into the actual workflows instead.
Studio design system, adapted — not rebuilt from zero
How I Got There
Audit, interviews, flows — then screens
I started with a design audit of the existing tool, then sat down with dispatchers to walk through their day-to-day. Those conversations became golden-path flows and a sitemap defining who could see and edit what, wireframed before a single screen was designed.
The Platform
What dispatch, drivers, and billing actually see now
One dashboard replaced the Access file — trips this week, incoming referrals, and available drivers, all live.
Results
What changed, operationally
2–3 days → 2+ weeks
Booking horizon dispatchers could plan against
Real-time
Driver tracking replaced phone-and-SMS check-ins
Mostly automated
Manual entry, largely eliminated from the workflow
The database is gone.
Dispatchers plan two weeks out instead of two or three days. Drivers show up in the system instead of on a paper form. Referrals land in one queue instead of three separate inboxes. That’s the point of replacing a spreadsheet with a platform — not a prettier screen, but a system a rural transit network can actually run on.
ROLE — Lead Product Designer, product ideation through design & development handoff.
Handoff documented in Notion and prototyped in Figma for the engineering team.