The important work was happening outside the dashboard.
At Northstar Freightworks, a shipment exception could have three people investigating it and nobody accountable for the next action.
Relay at Northstar Freightworks.
Northstar Freightworks runs regional freight coordination for independent carriers. Relay was its internal operations workspace. I joined as an embedded design lead after a proposed visual refresh had stalled. The real design problem was the unrecorded handoff between noticing an exception and owning it.
What I owned
I owned research planning, workflow design, interaction specifications, the coded prototype, and release review. I facilitated the pilot readouts with Elena.
What I worked with
An existing network map, a shipment-detail API, and a component library. Five engineers implemented the production changes; Jonah assembled the comparison data.
The people I worked with
- Elena Brooks
- Product manager · scope and rollout
- Arun Mehta
- Engineering lead · event model and integration
- Maya Ortiz
- Dispatch lead · field access and pilot
- Jonah Reed
- Analyst · record sampling and measurement
The tracking service and carrier contracts were outside our scope. We could expose missing information, but could not make it arrive sooner.
The spreadsheet was doing the important work.
The dashboard was technically accurate and practically unhelpful. Every shipment looked equally important. An operator needed to cross-reference a map, a tracking table, carrier emails, and a shared spreadsheet just to understand a single delay.
The original brief was to “make the dashboard more modern.” Shadowing the team revealed a different problem: nobody could quickly tell which exceptions needed a decision, who owned that decision, or what had already been tried. A visual refresh would have made the same uncertainty look better.
We had sixteen weeks, incomplete carrier data, and a legacy tracking service we could not replace. The design had to make uncertainty visible without creating another stream of alerts.
From an exception record to a design requirement.
| Record | Exception | What the history showed | Code | Design consequence |
|---|---|---|---|---|
| R-0842 | Delayed pickup | Two carrier calls; no accepted owner | Ownership gap | Claim before contacting |
| R-0761 | Missing scan | Heartbeat received; no movement for 3h | False freshness | Separate event and movement |
| R-0910 | Address check | Resolved in chat, still open in queue | Split record | Resolution with a reason |
| R-0658 | Failed delivery | Night shift inherited a silent flag | Handoff gap | Owner and next check-in |
Three directions, one expensive wrong turn.
Jonah and I sampled 186 closed exception records from January, balanced across delayed pickups, missing scans, address checks, and failed deliveries. We linked event histories to dispatch notes, then coded the first moment an owner became explicit. An email being sent did not count as ownership. A named person accepting the next action did.
The first concept was a map-led control room. It looked persuasive in a review and failed in shadowing: operators immediately asked for a sortable list. A pure inbox went too far the other way. In two route-planning tasks, participants lost the spatial relationship between stops. I kept a ranked queue beside the existing map and stopped treating the map as the starting point.
I worked with Arun on a small interaction contract before drawing the final screens: an event can be received without representing movement; an exception can be seen without being claimed; a claimed exception can still require reassignment. Those distinctions became the API states and the language in the drawer.
Read the three directions and why two lost
01 · Map-first control room
Strong spatial overview, weak daily triage. Operators could not identify unowned exceptions quickly enough.
02 · Full-screen exception inbox
Fast prioritization, lost route context. A full-page shipment detail made returning to the queue expensive.
03 · Ranked queue with an adjacent drawer
Preserved the existing map and kept the operator in the list. We chose this direction with dispatch after task-based prototype reviews.
Keep the queue visible while a decision is open.
A queue with a point of view
Exceptions are ordered by operational impact, with clear ownership and a visible reason for each flag.
The whole story beside the map
Carrier events, customer commitments, and teammate actions share one chronological view.
A resolution that actually closes the loop
Every action records an owner and next check-in. Resolved items keep their history instead of disappearing.
Exceptions
The night shift broke our first version.
I ran two rounds of moderated testing with eight operators, including three from the night shift. Participants worked through delayed pickups, missing scans, and a handoff in progress. We then piloted with two dispatch teams for four weeks.
“Acknowledged” was mistaken for resolved.
Revision. Replaced it with “I’m investigating” and a separate resolution action.
Readout. All 8 participants distinguished the two states in the second round.
The map refreshed and moved during a decision.
Revision. Preserved map position while the detail drawer was open.
Readout. No task interruptions from map movement in the retest.
Stale information looked as trustworthy as live data.
Revision. Added a source timestamp and a plain-language freshness state.
Readout. 7 of 8 participants noticed missing data without prompting.
A faster handoff, with an unfinished edge.
Pilot readout · Four weeks · Two dispatch teams
faster resolution
Median 42 → 26 minutes
fewer duplicate actions
23 → 16 per 100 exceptions
preferred the new workflow
Post-pilot operator interviews
In the four-week pilot, median resolution time moved from 42 to 26 minutes across 312 comparable exceptions, a 38% reduction after rounding. The comparison used 298 exceptions from the preceding four weeks. We counted from exception creation to a recorded resolution and excluded major weather incidents in both periods.
Duplicate carrier contacts fell from 23 to 16 per 100 exceptions. We could not isolate the interface from a new shift-overlap policy introduced in week two. I treated the result as a useful operational signal, not a causal claim about design.
Elena approved rollout to the remaining dispatch teams. The slowest carrier still had unreliable scans; freshness labels made that limitation visible but did not solve it. We kept carrier escalation on the backlog and retained the legacy map for route planning.
I spent the first week making the map concept presentable when a rough queue would have answered the harder question. Next time I would take the least polished version onto the night shift before the first stakeholder review.