Design a dashboard around a decision, not a collection of metrics

A manager opens a dashboard showing enquiries, employee workload and an alarming share of overdue tasks. The data is present, yet a separate export is needed before discussing it with the team. Which records require intervention? Why are they delayed? Who can change the situation?

Start with a recurring question: “Which customer tasks risk missing their agreed deadline today?” This identifies the relevant data, update frequency and person using the screen. “How is the company doing?” is too broad to guide the first operational interface.

For each metric, describe a possible action. When its value changes, what should the user investigate? Which details will they need? If that is unclear, the number may belong in a periodic report rather than on the operational home screen. Having access to data does not make every available measure necessary to display.

First define what overdue means. A contractual deadline, an internal promise and the next-contact date can refer to different events. If teams use one label for several meanings, a polished interface may simply make the wrong interpretation faster.

An operational measure needs a known source, calculation and update time. Some records may have arrived an hour ago and others yesterday. A combined total may therefore need an explanation. When a source is unavailable, showing the age of the last known data is more useful than presenting a number that merely looks current.

Decide who corrects the original record as well. A manager should not have to edit a summary figure manually to make a report look right. Changes belong in the system responsible for that fact and should flow predictably to the overview. This decision often reveals that the problem extends beyond visualisation.

A signal needs a path to detail: customer, stage, last contact, expected event and accountable owner. For an illustrative late enquiry, waiting for the customer differs from a failed transfer between systems. Both may produce the same red indicator while requiring different actions.

Describe the journey as deviation, supporting context, responsible role, action and resulting state. At each step, the user needs enough information to continue without reconstructing events across several conversations. The dashboard does not have to become another full CRM, but it must offer a usable handoff.

In the Banex case, workload, task and document information connects to a shared client base and working sections. This provides a concrete way to discuss the value of linked information. It is not evidence of a particular time saving or revenue increase; those outcomes require separate measurement.

A filtered table may be sufficient when people need to select requests by deadline and owner. A process view can help trace handoffs. Where a decision depends on object locations, distances or routes, a spatial representation has a clearer purpose.

Test the user’s path with a small sample before adding visual complexity. Apply the same questions to each design: did the person notice the exception, locate its cause and choose a next step? Compare task completion rather than the impression made by a presentation.

Not every question requires continuous observation. A weekly report, an exception notification and a live workspace serve different purposes. A manager may only need a message about a specific problem, with a link to its details. Choosing when information arrives is part of the design, alongside deciding how it looks.

Prepare several anonymised situations: normal progress, a delay, conflicting sources and a record without an owner. Ask a future user to explain what is happening and how they would proceed. Note where they need another call or export. These observations reveal more than asking whether the design feels convenient.

After launch, examine the actual task: steps taken before a decision, records still lacking an owner and continued use of workaround spreadsheets. Avoid attributing fewer errors to the dashboard without investigating other changes, such as staffing, business rules or the volume of incoming requests.

The first release can focus on one process and one role. The article on choosing a workflow to automate develops the related prioritisation question. For a dashboard discussion, bring a frequent management question, its sources and the action that should follow. That gives the interface a specific job.