Designing a Dispatch Management Dashboard for Real Operations, Not a Generic Admin Panel

The Problem #

The first version of the dispatch dashboard was a data table with every field the order record had — status, timestamps, addresses, driver, notes, POS metadata. It was technically complete and practically unusable: a dispatcher juggling a dozen active deliveries couldn't scan it fast enough to make a decision under time pressure.

Context #

I built the table the way I'd design an admin panel for myself as a developer — show everything, let the user filter. A dispatcher isn't debugging the system; they're making fast, repeated decisions about who delivers what, next.

What I Tried #

Added filters and column sorting, assuming the problem was findability, not information density.

What Went Wrong #

Filters help when you know what you're looking for. A dispatcher scanning for "which orders need a driver assigned right now" doesn't start with a filter — they need that to be visually obvious at a glance, not something they query for.

The Solution #

Redesigned around the actual decision a dispatcher makes repeatedly: status became a color-coded, glanceable indicator instead of a text column, orders needing action sorted to the top by default, and every non-decision-relevant field (POS metadata, internal notes) moved behind a click-to-expand detail view instead of sitting in the main table.

<OrderRow
  status={order.status}
  // Color and icon carry the "needs attention" signal at a glance —
  // the dispatcher shouldn't have to read text to triage.
  statusIndicator={<StatusBadge status={order.status} />}
  needsAction={order.status === "pending" && !order.driverId}
/>

Why It Works #

A dashboard for someone operating under time pressure needs the important state encoded in form, not just present in the data — color, position, and iconography convey "act on this now" faster than a sortable text column does, even though both technically contain the same information.

Lessons Learned #

"All the data is there and it's filterable" is a developer's definition of a good dashboard, not an operator's. The actual design question is what someone needs to notice in the first two seconds of looking at the screen.

What I Would Do Differently #

I'd talk to the actual dispatcher about their real workflow before building the first version of the table, instead of designing from the data model and only discovering the UX gap once someone tried to use it under real pressure.

Related Concepts #

Information hierarchy in operational UIs, status encoded as visual state, glanceable design vs. data-complete design.