Watching real users test the dashboard

A few weeks ago I wrote about designing dashboards people actually use, and how I leaned on existing UX research instead of guessing. Research is a great start, but at some point you have to stop reading and watch a real person click around in the thing you built. So that's what I did: I drove to the client, sat down with three people from three different corners of the company, and asked them to do their job on the live MVP. A planner, an operational employee and a team lead. No demo environment, no hand-holding, a realistic dataset.

Three testers is not a statistic, and that's fine. I wasn't after percentages. I was after the right three people: they cover planning, operations and team leadership, they'll work with the dashboard daily, and they'll be the ones onboarding new colleagues later. When three people from three different roles trip over the same thing, you don't need a bigger sample to know it's real.

How I tested

Six tasks, from "log in and look around" to "judge a leave request" and "find the capacity forecast and tell me what it means". After every task I asked one question: how easy was that, from 1 to 5? I deliberately didn't ask for one big grade at the end. A single 7.5 tells you nothing. A per-task score immediately shows you where it hurts. And I gave no hints, because the moment you start helping, you're testing your own explanation instead of your interface.

What held up

Orientation scored highest: 4.7 out of 5, with everyone finding their way around in about a minute. Reading the monthly numbers came in at 4.3, and finding a specific container on the map went smoothly for all three. One tester called the whole thing "a useful cockpit". Another said it would "prevent pulling information out of multiple systems", which was the core promise of the project, so I'll take that.

In other words: the part the research had prepared me for, KPIs up top, the right chart for the right question, a map for spatial data, worked. Finding information is a solved problem.

The task that humbled me

Then there was task two: handle an incoming alert about a container that has been sitting at a customer for too long. Lowest score of the day (3.7), longest duration (around five minutes), and the only task where all three testers needed help. Everyone found the alert just fine. Everyone could name the customer and the number of days. And then everyone hesitated at the same moment: after clicking the button.

What they said afterwards made the problem obvious in hindsight. One wasn't sure what actually happens after resolving an alert. Another found the difference between opening, handling and definitively closing an alert the most confusing part of the whole session. The team lead put it sharpest: the hard part was knowing which of my actions automatically notify someone, and which don't.

That's not a findability problem. It's a feedback problem. The interface let you act, but stayed silent about the consequences, so people quietly wondered whether their click had done anything at all.

Confirmation is part of the action

The fix wasn't a redesign. It was treating the moment after the click as part of the feature:

• Every action now answers back. Resolve an alert and you get a clear confirmation with the consequence spelled out: the alert is closed, it disappears from the open list for your colleagues too, and you can still find it under its resolved status. Approve a leave request and the confirmation tells you the driver has automatically been notified, because "does he get a message now?" was a literal question during the test.
• Every alert has a history. A small timeline per item: detected, seen, extended until, resolved, by whom and when. Two of the three testers independently asked for exactly this, one of them for audit reasons. Handled items stay findable instead of vanishing into nowhere.
• Predictions say how sure and how fresh they are. The capacity forecast was found, but its meaning needed explaining and nobody could tell how current it was. It now carries a confidence level and a "last updated" timestamp, so a forecast reads as a forecast and not as a fact.
• Filters got more literal. One tester searched for a container first by customer, then by place, and wished out loud for both. Customer and place are now two separate filters you can combine, instead of one shared search box.

Fast also means offline

The other half of "a dashboard people actually use" is that it has to keep working when conditions aren't perfect. These users walk around warehouses and yards; wifi comes and goes. So performance here isn't just a Lighthouse score:

• Never a blank screen. Skeleton placeholders match the exact dimensions of what they're loading, so the page has its shape within milliseconds and nothing jumps around.
• Two layers of cache. The browser keeps the last known data per view and shows it instantly while fresh data loads behind it, and the server caches shared queries so twenty open dashboards don't mean twenty times the database load.
• Offline isn't an error state. Lose connection and the dashboard keeps showing the latest data it has, with a clear banner saying so. Actions you take while offline, resolving an alert, approving leave, go into a queue and sync automatically the moment you're back online, with the same confirmation when they land. A decision made in a dead spot of the warehouse shouldn't evaporate.

Stale data is still flagged as stale, because in logistics, quietly showing yesterday's numbers as if they're live is worse than showing nothing.

The takeaway

The usertest validated the big bet: bringing scattered information into one place works, and all three testers expected it to make their daily decisions faster and better grounded. But it also exposed the blind spot of building from research alone. I had obsessed over how information enters the screen and barely thought about how an action leaves it. Users don't just need to see the state of the world. They need to see that they just changed it. That confirmation, the little "done, and here's what happens next", turned out to be the difference between a dashboard that informs and one that people trust with their work.