Jerome Leland has spent fifteen years watching dashboards fail. Not because the data was wrong, but because the people who needed them simply stopped looking. A real-time dashboard that nobody opens isn’t a tool—it’s an expensive screen saver. The problem, he’s learned, is rarely the technology. It’s a breakdown in the unspoken contract between the builder and the viewer. That contract has three clauses: the numbers must be right, they must be timely, and they must answer the question the viewer is actually asking. Break one, and trust erodes. Break two, and the dashboard becomes decoration.
The First Clause: Correctness Is a Process, Not a State
Most dashboards start with a small lie. Not a deliberate one, but a lie of omission. The data gets pulled from a source that was never built for real-time consumption. A batch job that runs every six hours. A table an intern updates manually on Tuesday mornings. The dashboard shows a number with a timestamp, and that timestamp creates a false sense of precision. The viewer sees “Last updated: 9:42 AM” and assumes the underlying data is fresh. But the pipeline feeding that number might have last run at midnight.
Jerome’s rule is blunt: expose the freshness of the data, not just the freshness of the query. A dashboard should carry two timestamps. One for when the visualization was rendered. Another, more prominent one, for when the source data was last validated. If the source is a batch job that runs at 2 AM, the dashboard should say “Data as of 2:00 AM EST” somewhere the viewer can’t miss. This single practice eliminates the most common source of distrust: the moment a stakeholder discovers the number they’ve been citing all morning was already stale when they first saw it.
Correctness also means handling the edge cases that pipelines ignore. What happens when the source system returns a null? What happens when a join fails silently and the dashboard shows a zero instead of an error? A trustworthy dashboard is opinionated about failure. It doesn’t hide it. A metric tile that can’t be computed should display a clear, calm error state—not a blank space, not a zero, and certainly not the last known good value without a warning. The viewer needs to know the difference between “nothing happened” and “I don’t know what happened.”
The Second Clause: Timeliness That Matches the Decision Cycle
Real-time is a seductive word. It suggests omniscience, a live pulse of the business. But most decisions don’t need sub-second data. They need data that’s fresh enough to act on, and no fresher. A dashboard that updates every five seconds for a metric that changes meaningfully once a day creates noise. Noise erodes trust because it trains the viewer to ignore fluctuations. When a real shift occurs, it gets lost in the jitter.
Jerome advocates for what he calls “decision-aligned latency.” If the team meets weekly to review performance, the dashboard should reflect a weekly aggregation, with the ability to drill down to daily granularity only when investigating anomalies. If the dashboard monitors a production system where minutes matter, then a one-minute refresh cycle is appropriate—but it must be paired with clear alert thresholds. The refresh rate itself becomes a signal. A dashboard that updates every second is making a promise that every second contains actionable information. That promise is rarely kept.
Timeliness also applies to the data pipeline. A common failure mode is the “late-arriving fact.” An e-commerce transaction might be recorded in the dashboard’s source table hours after the purchase, thanks to payment processing delays. If the dashboard simply queries the latest rows, it will show a dip in sales that never actually happened. The fix is to design the pipeline to handle late arrivals explicitly—either by using a watermark and updating historical periods, or by clearly labeling data that is still within the late-arrival window. The viewer should never have to mentally adjust for a known pipeline quirk. The dashboard must do that work.
The Third Clause: Answering the Unasked Question
Stakeholders rarely articulate what they really need. They ask for “a dashboard that shows sales.” What they mean is “I need to know, before my boss asks me, whether we are on track to hit the quarter, and if not, why not.” The difference is enormous. The first request leads to a big number on a screen. The second leads to a comparison against a target, a trend line, and a breakdown by the dimensions that explain variance.
Jerome’s approach is to spend the first half of any dashboard project in conversation, not in code. He asks: What decision does this dashboard inform? What is the cadence of that decision? What would make you take action? What would make you do nothing? The answers become the design constraints. A metric that never triggers action doesn’t belong on the dashboard. It belongs in a weekly email report, or nowhere. The dashboard is a tool for directing attention, not a museum of interesting numbers.
This principle extends to the layout. The most important metric—the one that answers the primary question—sits at the top left, where the eye lands first. Supporting context flows to the right and downward. Filters are global, not per-chart, because a dashboard with inconsistent filter states is a dashboard that tells two different stories at once. Color is used sparingly: red for things that require immediate attention, blue for everything else. No traffic-light colors that imply judgment without context. A metric that is 2% below target is not necessarily “red.” It depends on the volatility of the metric and the cost of being wrong.
Designing for the Skeptical Viewer
Assume every person who opens the dashboard is skeptical. They’ve been burned before. They’ve made decisions based on numbers that turned out to be wrong. They’ve been embarrassed in meetings. The dashboard must earn their trust anew each time they load it.
One way to do this is to make the data lineage visible. A small “source” link or icon next to each chart that, when clicked, shows the exact query, the tables involved, and the last time those tables were updated. This isn’t for the average user. It’s for the power user who will validate the dashboard and then vouch for it to others. If that person finds an error and can’t trace its origin, they’ll tell everyone. If they can trace it and see it was a source system issue, they’ll still be frustrated, but they’ll trust the dashboard more because it didn’t hide the problem.
Another technique is to build in deliberate consistency checks. If the dashboard shows total revenue and also shows revenue by product line, those two numbers must reconcile. A viewer who notices a discrepancy will assume the entire dashboard is unreliable. Automated tests that compare aggregate numbers to their breakdowns should run every time the data refreshes. If a reconciliation fails, the dashboard should flag it prominently rather than displaying conflicting numbers.
Handling Anomalies Without Breaking Trust
Every dashboard will eventually display something that looks wrong. A spike, a drop, a flatline where there should be variance. The difference between a trusted dashboard and an ignored one is how it handles these moments. A dashboard that simply shows the anomaly forces the viewer to investigate. The viewer may not have the time or the skill. They’ll see the anomaly, feel a pang of anxiety, and then learn to ignore it. Over time, they ignore the dashboard entirely.
A better approach is to pair anomaly detection with lightweight annotation. When a metric deviates beyond a threshold, the dashboard should surface a possible explanation. “Revenue dropped 15%: this coincides with a 20-minute checkout outage recorded by the platform team.” This annotation doesn’t need to be perfect. It needs to show that the dashboard is aware of its own context. The viewer can then decide whether the explanation is sufficient or whether further investigation is warranted. The key is that the dashboard doesn’t leave the viewer alone with a scary number.
Annotations also serve as a log of organizational memory. When someone investigates an anomaly and determines the cause, that explanation should be recorded and attached to the time period. Six months later, when a similar pattern appears, the dashboard can surface the previous explanation. This prevents the cycle of rediscovery that plagues operations teams. It also builds a cumulative record of why things happen, which is the foundation of institutional knowledge.
The Hidden Cost of Over-Customization
Organizations often demand dashboards tailored to every role. The marketing team wants one view. The finance team wants another. The CEO wants a third. This leads to a proliferation of dashboards that all show slightly different versions of the same metrics. The numbers don’t match because the filters are different, the time zones are different, or the definitions are different. In the resulting arguments over whose dashboard is “right,” trust in all of them evaporates.
Jerome’s counterintuitive advice is to resist customization. Build one dashboard per metric domain, with a single source of truth for each number. If the CEO and the marketing manager need to see revenue, they should look at the same revenue number on the same dashboard. The CEO might see a higher-level aggregation, but drilling down should reveal the same data the marketing manager sees. Role-based access should control who can see what, not create divergent copies of the truth. When everyone is looking at the same numbers, conversations shift from arguing about the data to acting on it.
This requires organizational discipline. It means saying no to requests for “just a quick custom view.” It means investing in a semantic layer that enforces consistent definitions across all consumption points. The payoff is that when someone cites a number in a meeting, nobody asks “which dashboard did you get that from?” The number is the number, and the only question is what to do about it.
Maintenance: The Unsexy Foundation of Trust
Dashboards rot. Data sources change. Business definitions evolve. A metric that was critical last quarter becomes irrelevant. A dashboard that isn’t actively maintained will, within six months, display numbers that are misleading or outright wrong. The viewers will notice. They’ll stop trusting not just that dashboard, but all dashboards produced by the team.
Jerome treats dashboard maintenance as a first-class engineering practice. Every dashboard has an owner, and that owner is accountable for its accuracy. Ownership isn’t a permanent assignment; it rotates. This prevents any single person from becoming a bottleneck and ensures that multiple people understand how the dashboard works. Dashboards are version-controlled, with changelogs that explain what was modified and why. When a metric definition changes, the dashboard reflects the change and notes it clearly. There is no such thing as a silent update.
Deprecation is part of maintenance. Dashboards that are no longer used should be taken down, not left to accumulate digital dust. An unused dashboard is a liability. Someone will eventually stumble upon it, see outdated numbers, and make a decision based on them. A clean, deliberate archive process—with redirects to the current source of truth—prevents this. It also signals to the organization that the data team is in control of its outputs.
Building the Feedback Loop
Trust is a relationship, and relationships require communication. A dashboard that never asks for feedback is a monologue. Jerome embeds a simple feedback mechanism directly into every dashboard: a single question, “Did this help you make a decision today?” with a thumbs-up or thumbs-down. The responses are anonymous and aggregated. They provide a continuous signal about whether the dashboard is fulfilling its purpose.
More importantly, the feedback loop closes. When a dashboard receives consistently negative feedback, the owner investigates. They talk to users. They watch how the dashboard is actually being used—or not used. They identify the gap between the intended decision and the actual need. Then they update the dashboard and announce the change. This cycle of listening and responding is what transforms a dashboard from a static report into a living tool. Users who see their feedback lead to improvements become invested in the dashboard’s success. They become advocates, not just consumers.
Frequently Asked Questions
How often should a dashboard be refreshed?
The refresh rate should match the decision cycle of the people using it. If decisions are made weekly, a weekly refresh is sufficient. If the dashboard monitors operational systems where minutes matter, a refresh every one to five minutes is appropriate. Avoid sub-minute refreshes unless the data itself changes that quickly and someone is actively watching. The goal is to provide data that is fresh enough to act on, not to create a false sense of real-time precision.
What is the single biggest mistake in dashboard design?
Displaying metrics without context. A number on a screen means nothing unless the viewer knows whether it is good or bad, how it compares to a target or historical trend, and what factors are driving it. Every metric should be accompanied by a comparison—to a previous period, to a target, or to a forecast—and a way to explore the underlying dimensions. Without context, the viewer is left to invent their own story, which is often wrong.
How do you handle discrepancies between dashboards?
Discrepancies usually arise from differences in definitions, filters, or refresh timing. The long-term solution is to enforce a single semantic layer that all dashboards query. In the short term, document the exact definition, filters, and refresh schedule for every metric directly on the dashboard. When a discrepancy is reported, treat it as a bug and investigate immediately. Publicly resolving discrepancies and explaining the root cause builds trust. Ignoring them destroys it.
Should dashboards be designed for mobile devices?
Only if the decisions they support are made on mobile devices. A dashboard designed for a wall-mounted screen in an operations center has different constraints than one viewed on a phone during a commute. Mobile dashboards should be ruthlessly simplified: one or two key metrics, large touch targets, and minimal scrolling. If a dashboard requires detailed exploration, it is better suited to a desktop or tablet. Do not compromise the desktop experience to accommodate mobile users who will never actually use it.
How do you know when to retire a dashboard?
Track usage. If a dashboard has not been viewed in 90 days, flag it for review. Contact the intended users and ask whether it is still needed. If no one claims it, archive it. If someone does claim it but usage remains low, investigate why. The dashboard may be answering a question that is no longer relevant, or it may have been replaced by another tool. Retiring unused dashboards reduces clutter and increases confidence in the ones that remain.