The same dashboard, four different systems
Imagine your organization manages a transport fleet and wants a dashboard to monitor logistics. A reasonable request. But what is the actual goal behind that request?
Depending on the answer, you will build a fundamentally different system. Even if, on the surface, it looks the same.
Scenario 1: Detecting and resolving operational issues
You want to see problems the moment they occur, so you can intervene immediately. Think of a delay in part of a route, a vehicle deviating from the schedule, or a connection that is at risk.
In this design, signalling and prioritization are central. The dashboard does not show all information, but filters for what requires attention. Alerts are prominent. Navigation to the issue is fast. The user does not have to search; the system points the way.
Questions you, as the commissioning client, must be able to answer:
-
How does a user currently know there is a problem, and how long does that take?
- Are there different levels of urgency between issues, and how are they currently weighted?
- Should the system also suggest corrective actions, or only signal that something is wrong?
Scenario 2: Predicting supply and demand for efficient deployment
You don’t want to react to problems, but prevent them. By predicting where and when capacity will be needed, you can plan the fleet more efficiently and reduce costs.
This design is not about real-time alerts, but about patterns and forecasts. Historical data is the raw material. The dashboard helps planners look ahead, rather than track what is happening right now. Visualizations show trends and expected peaks. Predictions might be generated directly in the system, or data may be exported to an external planning tool.
Questions you, as the commissioning client, must be able to answer:
-
On what data are the forecasts based, and how reliable are they today?
-
Does the planner perform the analysis in your own system, or in an external tool?
-
If the system can generate forecasts: do you want to see the outcomes, or primarily prepare the data for export?
Scenario 3: Management information to monitor KPIs
You want to know whether the organization is performing as expected. Not at the level of individual trips, but at the level of the organization as a whole. Have the objectives been met? Where are the deviations? What has the trend been over the past few months?
This design requires abstraction and context. KPIs are by definition a simplification of reality; a good dashboard also allows you to zoom in to the operational level when a number needs explanation. The user is not the planner but the manager, and they have different questions than the people executing the work.
Questions you, as the commissioning client, must be able to answer:
- What are your KPIs, and how are they currently calculated?
-
How important is it to see trends over time, in addition to the current status?
-
Which operational-level information needs to be accessible from the KPI overview?
Scenario 4: Monitoring whether agreements are being met
You have obligations towards partners or customers: delivery times, arrival times, service levels. You want to know whether those are being met and, if not, why not and what you can do about it.
This design focuses on deviations from expectations. Everything that is on schedule is noise; the system does not need to highlight it. What matters is what goes wrong and whether there is still time to intervene. In some cases, the user must also be able to communicate directly from the system: informing a partner about a delay, sending an update to a customer.
Questions you, as the commissioning client, must be able to answer:
- Is it enough to show problems when they occur, or do you also want to be able to anticipate them?
-
Does your organization communicate with partners or customers from within this system, or via a separate channel?
-
What is the threshold for a notification: every deviation, or only deviations beyond a certain margin?
Make your insights explicit
These are four answers to the same question. Four different designs, four different priorities, even though from the outside you might barely be able to tell the dashboards apart.
In practice, designers and developers get to work on what is asked and fill in the rest based on assumptions. Sometimes those assumptions are right. Often they’re just slightly off.
The result is a system that technically meets the specifications, but does not fit smoothly in day-to-day operations. Users who find workarounds. Planners who fall back on their own spreadsheets. A dashboard that no one opens anymore.
You don’t prevent that by building better. You prevent it by asking the right questions earlier. What problem is this system supposed to solve? For whom, and in what situation? What does success look like: for the user, for the organization, for the chain?
Not harder. Just more explicit.
This doesn’t require extra budget or a longer project. It requires a deliberate step at the start: making explicit the insights you already have but haven’t articulated yet. So the design team doesn’t have to guess, but can actually design.
And so the system you deliver doesn’t just work in theory, but works for the right people, in the real operational context.
