Designing a data dashboard that helps someone make a decision

When I open a dashboard, I want to understand the situation and what I can do about it. I do not need the company’s entire history, fifteen indicators and a world map when the operation has two warehouses. Building a screen that looks like a lot of work is relatively easy. Building one that someone uses for a specific decision takes more thought.

I begin with the reader’s task, establish what the numbers mean, sketch a layout and test a few cases. Charts enter the process fairly late. That saves me from defending an impressive visualisation that answers a question nobody asked. It is a useful saving in both time and professional pride.

This guide uses a synthetic delivery dashboard. Every number is invented for the exercise and has no connection to a real client. The reasoning can be applied in Excel, Tableau or a Power BI report. Product terminology and interactions differ, so I use dashboard here in the general sense of a view for monitoring a situation.

A recurring decision gives the project a boundary

Imagine someone coordinating deliveries. Each morning, they want to identify overdue shipments needing investigation and check whether completed deliveries are becoming less punctual. The questions are related but concern different datasets. One describes open work at a particular moment. The other summarises events within a selected period. I record that distinction from the beginning.

I ask what the reader can do after seeing the result. They might inspect a shipment, contact the operations team or compare carrier workloads. The dashboard should help them reach the relevant records. If there is no meaningful next step, a one-off analysis or a short update may serve them better than another screen to monitor every day.

I do not automatically assign a design style to a job title. An executive sometimes needs detail; an operations team sometimes needs only an alert. I ask about frequency of use, device, process knowledge and available time. Tableau’s design guidance also starts with purpose and audience. Those answers become part of a brief that can later be checked.

The metric definition belongs in the design

In this example, punctuality is the share of deliveries completed in the selected week that arrived no later than the agreed deadline. The denominator includes completed deliveries with both a known deadline and a known delivery time. Arrival exactly at the deadline counts as on time. A real process also needs a time zone and a precise boundary rule so that systems classify the same event consistently.

This definition uses delivery date. A report based on the planned delivery date would answer another question and could include shipments that have not arrived yet. Neither definition is automatically correct for every purpose. I record the choice beside the measure because the label “on-time delivery” does not explain which records entered the calculation.

I show completed deliveries that cannot be assessed in a separate data-quality count. Missing information should not quietly improve the rate. The operational view also contains open overdue shipments at a stated moment. I do not add that figure to late completed deliveries from the week: a current stock and a historical flow do not share the same scope.

A small example exposes calculation errors

Suppose 104 deliveries were completed during a week. Both required times are available for one hundred, while four lack an agreed deadline. Among the hundred assessable deliveries, carrier A handled eighty and completed seventy-two on time. Carrier B handled twenty and completed fourteen on time. The four unassessed deliveries stay outside the rate table and receive a separate quality indicator.

The overall rate is 86 divided by 100. Simply averaging 90 and 70 percent would give 80 percent because it assigns equal weight to both carriers. A handled four times as many assessed deliveries. To calculate the overall share of punctual deliveries, I add the numerators and denominators. I apply the same check to weeks, regions and other groupings.

Coverage is one hundred out of 104 completed deliveries, or approximately 96.15 percent. I therefore avoid presenting 86 percent as an unqualified result for every completed delivery. A card can say “on-time rate for assessed deliveries”, with “four deliveries unassessed” beside it. The label is longer, but the reader can see which part of the process remains unknown.

The total can change while group rates stay stable

For a second synthetic week, reverse the proportions. A now has twenty assessed deliveries, eighteen on time. B has eighty assessed deliveries, fifty-six on time. Their rates remain 90 and 70 percent respectively. The combined result nevertheless falls to 74 percent because a larger share of deliveries belongs to the group with the lower rate.

A card saying “down from 86 to 74 percent” cannot explain that mechanism by itself. I need counts or carrier shares beside it. These numbers do not show that either carrier’s own rate deteriorated. I first inspect the composition of the data, then investigate why it changed. The dashboard should support that question instead of offering a confident story based only on the overall percentage.

If I include a target, I identify its source and scope. A 95 percent target could be an assumption in an exercise, but should not pretend to be an industry standard. I would not recommend replacing a carrier based on this tiny table. That would require more context about routes, shipment types, deadlines and the conditions each group handles.

Start the layout with a sketch

At the top, I place the question, date range and last successful refresh time. Then I show the main result, the assessed delivery count and the missing-data information. Carrier comparisons and a trend follow. A separate view leads to open overdue shipments. Available source tables do not all need a place on the first screen.

A paper sketch is enough to test the sequence: what is the result, where is the problem, which records should I inspect? If explaining the layout requires a lengthy tour, I simplify it before building. Moving a rectangle in a sketch is cheaper than rebuilding a completed set of interactions and calculations.

Microsoft’s dashboard guidance describes an overview with access to detail in underlying reports. I use that principle to control the amount of content. I do not turn it into a universal requirement to show exactly three charts. The number of views should follow the task, readability and the actual display size.

Choose a chart for the comparison

Horizontal bars can compare carrier rates, with percentage labels and assessed delivery counts. A line can show change across successive weeks. If the reader needs exact identifiers for overdue shipments, I use a table. Every piece of information does not need to become a chart. A well-labelled table is often the shortest route to completing a task.

I check scales and units. Bars comparing quantities need an honest shared baseline, and a percentage should not resemble a delivery count. A trend needs a clear axis and range. Changing scales across views can exaggerate a small difference. During review, I inspect the conclusion suggested by the picture before reading every label.

A map earns its place when location is part of the question and supports useful action. For ranking two warehouses, bars may be clearer. I similarly remove decorative depth, shadows suggesting a third dimension and icons that compete with the data. They need a reason to exist, just as an additional column in a report does.

Filters change the meaning of the visible result

After selecting carrier B, the card should show fourteen on-time deliveries out of twenty assessed, or 70 percent. I check that the filter updates the appropriate card, trend, detail table and missing-data count. If a view intentionally continues to show the whole population as a comparison, I label that scope explicitly. Otherwise, users may compare numbers covering different records.

Active filters need to remain visible. I provide an easy reset and a sensible default range. A new reader should not have to guess five settings to escape an empty screen. I also test clicking a bar, switching tabs and returning to the report. An interaction becomes part of the result definition even if the tool created it with one click.

Filtering and highlighting have different effects. Highlighting can preserve the context of other groups, while filtering removes them from the visible set. The reader should recognise the difference without studying product documentation. In a brief test, I ask them to explain the denominator after clicking. If their answer differs from the calculation, I improve the label or interaction.

Colour supports meaning without carrying it alone

I limit the palette and use it consistently. If yellow identifies the selected carrier, I do not also use it as random decoration on every card. A late status gets text or another cue. Red and green alone are insufficient for someone who distinguishes colours differently, reads a printout or uses a poor-quality display.

W3C’s explanation of colour use says that information should not depend on colour alone. In practice, I add labels, a readable legend and additional cues. I also check text contrast, keyboard operation and access to data descriptions in the chosen tool. A restrained palette is not proof that the entire dashboard is accessible.

I inspect the view on the reader’s device. A phone may need a different ordering and fewer elements visible at once. Shrinking the desktop layout does not necessarily preserve readability. Long titles, tiny filter controls and information available only on hover quickly reveal the gap between a large-monitor mockup and actual use.

Empty screens and old data need a design too

I distinguish three states: zero late deliveries, no records matching a filter and no current data available. The first may be good news, the second may call for a different selection and the third may indicate a refresh problem. Displaying the same zero for all three would erase useful information. A short message should explain what is known and what action makes sense.

Refresh time needs precise wording. The time a query ran does not necessarily mean the source includes events up to that moment. A file received this morning may only contain yesterday’s activity. If an update fails, the user should see the age of the last valid data. Quietly presenting an old result as current undermines trust more effectively than an explicit error message.

I match refresh frequency to the decision. A weekly review does not automatically require minute-by-minute updates, while a dispatcher may find data from several days ago unusable. I record the requirement, process owner and route for reporting a failure. Someone will use the dashboard after the project ends, so responsibility for freshness needs to be as concrete as responsibility for the calculation.

Test the task as well as the appearance

I ask a reader to find the carrier with the lower rate, state its assessed delivery count and inspect one overdue shipment. Then I watch where they look and what they think the numbers mean. I avoid immediately guiding them. This exposes confusing labels more effectively than asking whether they like the dashboard, a question that often invites a polite yes.

I check the arithmetic independently. The test cases include the whole dataset, each carrier, an empty period, one record and missing dates. I reconcile results with a small separately calculated table. After a filter change, I calculate the denominator again. I also open the export if the reader will use one, because an image outside the application can lose its filter and freshness context.

The handover includes concise metric definitions, data sources, known limitations and an owner to contact. It does not need a manual describing every button. It needs enough context to understand the result and distinguish an error from intended behaviour. If a simple task requires lengthy training, I revisit the design before adding more instructions.

Preserve definition changes and export context

Suppose the team later changes the rate to use planned delivery date. I do not silently replace the calculation. I record when the definition changed, what it now means and whether history was recalculated. Otherwise, someone comparing an old export with the current view could mistake a methodological change for a change in carrier performance.

An export should retain its title, time range, active filters and data freshness. A chart copied out of the application can easily lose those details. Someone pasting it into a presentation should still be able to establish what the figure covers. I am particularly careful to distinguish a completed week from an ongoing period that will continue changing.

Not every reader needs shipment identifiers. I limit detail to information required for the task and follow the organisation’s access rules. Customer contact details should not be included merely for the designer’s convenience. Before sharing, I also inspect the report from a typical recipient’s perspective, because the author’s account may see more than the intended audience.

An exercise and the next iteration

Sketch this example on one sheet of paper. Include 86 percent, one hundred assessed deliveries, four unassessed deliveries and the A/B comparison. Separately show twelve open overdue shipments at a specified moment. Label that count so it is clear that it does not describe the same population as the weekly rate. Choose the implementation tool after the sketch makes sense.

Switch to the second synthetic delivery mix, producing 74 percent overall. Write one sentence explaining the change without claiming that either carrier’s own rate deteriorated. Then simulate an empty filter and a failed refresh. A design that honestly handles all these states gives you much more to discuss than a polished initial screen alone.

After release, I ask which decisions the dashboard actually supports and which questions still require manual searching. I remove unused elements and improve misunderstood ones. If necessary, I return to KPI definitions and data quality. I develop a useful dashboard around how people use it, rather than the number of chart types available in the software.