Digital products ·
A business dashboard: from data to decision
A dashboard is often commissioned as a screen that should show everything. Sales, costs, advertising, team capacity and several other indicators are placed side by side, charts are selected, and the work appears complete. Yet a dashboard creates value before visualisation, when it becomes clear which decision someone should make from the data.
A request for a screen can conceal the management question
“We need a dashboard” names a form without defining the task. A director may need to see a cash gap earlier, compare business units, understand a fall in sales or find the stage where an order stops moving. Each question requires different data, timing and depth.
Starting with every available metric quickly fills the screen with whatever the CRM, advertising account and accounting system can export. Such a dashboard demonstrates the volume of data without helping anyone choose the next action. The user still opens spreadsheets, messages colleagues and assembles an explanation by hand.
I therefore begin the first dashboard prototype before the charts. The initial question is simple: which change must a person notice, and what will they do after seeing it?
One dashboard serves one role
An owner, a finance director and a sales lead view the same business from different heights. The owner needs the stability of the whole, the finance director needs cash movement and variance from plan, and the sales lead needs the state of the funnel and the causes of individual losses. A universal screen forces everyone to discard irrelevant information mentally.
The role determines both the metrics and their order. A person should see the current state first, recognise a deviation next, and then be able to inspect its cause. The dashboard becomes a short path from signal to investigation rather than a collage of charts.
One person may genuinely need several modes. These work better as separate levels: an overview, a diagnostic view and a list of records that can be acted upon. Each level retains one question, while detail appears when requested.
A metric begins with an agreement
A label does not make a metric unambiguous. Revenue may mean issued invoices, received payments or completed documents. A new customer may be counted from an enquiry, a first purchase or a unique legal entity. When departments use different definitions, a polished chart merely fixes the disagreement inside the interface.
Every metric needs a formula, source, owner, refresh interval and acceptable delay. Cancellations, refunds, duplicates and incomplete records also require explicit treatment. This may look like preparation, yet it is the work that makes the screen trustworthy.
Once these agreements exist, the data architecture becomes visible. One verified spreadsheet may be sufficient. A different case may require connections between the CRM, payments, advertising systems and an internal database. The solution should grow from the actual number of sources and decisions instead of an early ambition to build a large analytics platform.
Good visualisation exposes a deviation
A number without context rarely supports action. Revenue of five million says little without a target, a previous period, seasonality or the composition of receipts. A metric needs a reference point, and a deviation needs a readable scale.
The main result should appear before the detail. Comparisons are easier to read on a common scale, change belongs on a timeline, and composition needs a limited number of distinguishable parts. Colour is useful when it communicates state rather than decorating the surface. If every element requires its own explanation, the screen returns the very work it was meant to remove.
Filters should also continue the question. Period, business unit, region or owner help when they reveal a cause. Too many filters expose the structure of the database and make the user rebuild the report on every visit.
AI can explain, but it cannot repair the data
AI can accelerate dashboard work by proposing a structure, writing a query, matching field names, finding an anomaly and preparing a concise account of a change. It is particularly useful when a signal needs to be connected quickly with possible causes.
The model does not know what a particular organisation considers revenue, why a CRM field changed yesterday or which exceptions are acceptable in a given process. When source data contradicts itself, confident prose only conceals the error. An automated explanation should rely on agreed metrics and make the supporting facts visible.
AI is most useful between data and decision. It can call attention to a deviation, assemble context and formulate a question. The decision to change a price, stop a campaign or reallocate resources remains with the person responsible for the consequences.
A dashboard becomes a product after the first decision
A dashboard is tested by a changed action rather than a view count. A director sees a cash gap earlier. A team finds the stage where orders are delayed. Advertising spend is no longer judged separately from paid sales. A meeting begins with a shared state instead of reconciling several files.
After launch, it is necessary to see which elements people actually open, where they leave for the source system and which questions still require manual answers. Unused metrics can be removed, definitions refined and a meaningful deviation turned into an alert. The dashboard develops with the process it helps people see.
Within the Method, I treat a dashboard as a digital product. Its Concept is articulated through a decision, data becomes its material, and the interface constructs a path from state to action. A chart completes that structure, but it can never replace it.
A dashboard for a decision
If you need a dashboard, we can first define the management question, data sources and the decision it should support.