A dashboard operators actually use

The problem

The operations team starts every shift with the same question: what needs attention now? The dashboard answered a different question: what do we measure? It had 42 metrics, four date pickers, and no hierarchy.

Operators had built their own workaround. Every morning they exported the same numbers into a spreadsheet, sorted them by hand, and decided what to do. The dashboard was technically correct and practically unused.

What research changed

I spent two shifts with operators, watching how they worked rather than asking them to explain it. I also reviewed the spreadsheets they had built.

The workaround revealed the real information architecture:

• Now: what is late, blocked, or about to miss a promise.
• Next: what is queued for this shift.
• Later: what is trending in the wrong direction.

The existing dashboard was organised by data source. The operators organised by urgency. That mismatch was the design problem.

“I don’t need more data. I need to know which three things to touch first.” — Operations lead

The decisions that mattered

We replaced the metric wall with three priority lanes. The first screen answers “now”, “next”, and “later”. Everything else moved behind a secondary view.

We made every number actionable. A late shipment count is not useful on its own. The new view pairs each number with the next step: open the queue, assign an owner, or acknowledge the risk.

We designed for the 15-minute refresh. Instead of hiding the delay, the interface shows when the data was last updated and which decisions are safe to make before the next refresh.

We kept the dense table for the people who wanted it. The redesign did not remove detail. It moved detail behind intent.

What shipped

The new dashboard shipped to the operations team first, then to two adjacent teams. The component model was built with the frontend engineer so the priority lanes could be reused for other operational views.

What I’d do differently

I would define the data freshness model with the backend team before designing the states. We treated “last updated” as a UI detail, but it was a product decision that affected trust.

I would also test with a new operator, not only with experienced ones. Experienced operators knew which numbers to ignore. New operators needed the hierarchy to teach them.