How To Ensure That Your Dashboards Drive Decisions
Common blockers and how to overcome them
Introduction
So, you have meticulously designed and built a dashboard in response to a request from a stakeholder. Some time later, you discover that nobody is using it. Many organisations experience this proliferation of unused dashboards that quietly consume both analytics effort and compute costs. There is an additional risk in terms of missed opportunities to surface timely, curated insights that could materially improve business outcomes.
Successful dashboarding (repeatedly illuminating impactful business decisions) requires pro-active alignment with decision-making processes, maintaining trust, a sustainable maintenance framework and clear communication. In other words, they must be treated as decision systems.
I am an analytics consultant and founder of Lighthouse Data Analytics, with over 15 years’ experience spanning product analytics, business intelligence, and business analysis across the electricity, transportation, and travel sectors. In this article, I examine typical blockers that prevent dashboards from driving decisions and how they can be managed to promote sustained engagement and enhanced decision-making.
When the Request is not the real Problem
Not all stakeholders understand how to interpret their business need in data terms. If you build what is requested without investigating the ask you may deliver a dashboard that goes unused because it does not adequately address the business problem. This is why we treat stakeholder discovery as a structured diagnostic exercise, not a requirements-gathering formality.
- Guide your stakeholder through a discussion of the underlying business problem. Focus on Why as much as if not more than What or How. Then translate refined business requirements into a viable data specification.
- Drill down to the most critical business need. Create a tiered hierarchy of objectives to ensure the most critical decision driver is prioritised.
- Discuss the decision-making framework and understand clearly how the proposed dashboard will influence this. If necessary, advise changes or an alternative approach for best resolution of the business use case.
- Maintain frequent touchpoints during design and build to capture any dissatisfaction early and pivot accordingly. Sometimes stakeholders need to see a prototype before they can truly understand and articulate what they need. To that end, build a mock-up fast and be prepared to re-do requirements significantly.
When a dashboard is not needed at all
If the dashboard request is really a way of getting easy, regular access to a curated data source (i.e. for export to excel so the stakeholder can do self-serve analysis) then don’t build the dashboard. That would waste resources without necessarily increasing decision quality.
- Build a bespoke table in the relevant database (with appropriate quality or cost controls) and provide for direct connection to their spreadsheet.
- Maintain close ongoing relationships with your stakeholders so you understand their business context deeply before any particular request comes and can push back or re-frame credibly.
When conflicting or untrusted numbers erode trust
In the absence of a Single Source of Truth (SSOT), multiple versions of metrics can cause doubt as to which number is real. Once leaders lose confidence in the numbers, they either delay decisions or revert to intuition. Both outcomes undermine investment in analytics and the strategic pursuit of data-informed decision making.
For instance, there should only be one real number for a finite item like ‘orders received’, right? Well, if Sales reports all orders but Operations excludes cancelled orders and Finance only reports paid orders etc then you quickly get ‘disagreement’ — in other words it is possible to have divergence without any data errors or real contradiction.
- The applicable context / definition should always be clearly stated. This gives confidence and helps stakeholders interpret the data accordingly.
On another note, sometimes the company-wide definition of a metric evolves and the change is either not universally applied or is recognised more slowly by some teams. This can lead to dashboards then showing ‘wrong numbers’. Moreover, at any given point many people in an organisation may not be aware of the precise definition of a metric.
For instance, it might be that Retention (7 days) was originally defined as ‘any return visit within 7 days in a different session’ but is now ‘any return visit within 7 days, excluding the day of the original visit’. Such a distinction will not be obvious to any dashboard viewer or analyst.
- To prevent confusion and avoid wasted effort investigating perceived discrepancies, include a glossary in your reports stating the definition of key metrics (note where a standard definition has changed) and including a link to the company’s master data dictionary.
Unclear data ownership is another obstacle to trust. Stakeholders need to know that there is clear responsibility and accountability for ensuring the numbers are always correct.
- Summarise data quality measures in release documentation or in the launch communication. This could take the form of a RACI matrix (points of contact who are Responsible-Accountable-Consulted-Informed) and a breakdown of commitments and priority levels.
- This may involve an Operational Level Agreement (OLA) with the data engineering function which will include commitments to maintain an agreed level of data completeness, accuracy, uptime etc. These typically exist to fortify data pipelines / processes that support external customer-facing applications but can also benefit internal initiatives.
Multiple data siloes can lead to divergence due to a combination of random data errors, differing business requirements or maintenance procedures.
- As much as possible conduct ingestion, cleaning, transformations (i.e. categorisation, enrichment) and integration centrally within an enterprise data warehouse or company-wide database. Any separate reporting / platform deployments should then be ‘Last Mile’ reporting layer instances as opposed to isolated re-engineering scenarios.
When it takes too long to produce an updated report
Significant delays in producing reports or a dashboard taking too long to load / refresh can impact usage. Timeliness and user experience are important.
Get Iko-ei-Ojo Akoh’s stories in your inbox
Join Medium for free to get updates from this writer.
Performance issues can be symptoms of upstream architectural and process impediments rather than dashboard problems. Our Analytics Health Check can address such a situation by quickly surfacing bottlenecks that your team may have normalised.
- Keep in-dashboard data processing lean by constructing metrics or measures in source (SQL) tables as much as possible. Facilitate simple, robust data models by paying particular attention to efficient use of joins / filters / primary keys and partitions upstream of the dashboard.
If delays are due to heavily manual processes (i.e. obtaining / integrating off-platform data, custom categorisation in excel spreadsheets etc) then it is important to identify specific chokepoints.
- Automate or re-engineer the reporting cycle: remove unnecessary or low-value steps; eradicate duplication; re-deploy any custom automation to better-supported and more accessible locations. Use parallel runs for testing and to verify productivity gains.
On a similar note, a single point of failure due to dependency on a particular member of staff running a manual process at a particular time or on their unique knowledge / skills is a risk.
- This can be addressed by general upskilling across your team and / or productionising custom assets and diverting maintenance responsibility to core specialist business functions.
- Make documentation part of your governance / sign-off flow for every productionised dashboard: this may feel like extra overhead for start-ups and organisations with small teams but is worth it to mitigate risk and save effort / time for subsequent hires. You can use AI to help with authoring and maintaining documentation.
A dependence on translations / confirmations between departments (i.e. finance reconciliation run) need not always delay reporting.
- Where appropriate (i.e. operational or tactical decisions with no governance implications or external exposure), you can issue an initial report with a clearly stated confidence range pending final data confirmation; followed by an update when actuals come in (with a publication note to summarise any changes to metrics, advise any impact to recommendations / initial decision leaning etc). This approach preserves trust while improving decision timeliness.
When it is too difficult to find or refresh the report
If users are not sure where the report is hosted this can suppress engagement and thus impede better informed decision making. Treating dashboards as internal products (with launch / onboarding plans and success metrics) will optimise engagement and return on investment.
- Promote the dashboard in multiple, highly visible places: via custom emails and regular email bulletins; embed to slack or other high-traffic hub; intranet reporting landing page etc.
- Employ a push strategy such that dashboard insights / updates are delivered to users via scheduled email sends or via self-defined alerts.
Where special licences are required to access the report or see certain features then decisions need to be made beyond the dashboard build.
- Purchase licences which will enable mass participation if the cost-benefit analysis (assessing likely adoption, impact on decision-making and size of opportunity) supports this.
- Alternatively, switch to a reputable business intelligence tool that offers comprehensive viewing capabilities on unpaid tiers such that you can use the paid licences for builders and have unrestricted consumption.
- Either way, assess your data culture and embark on a journey (company-wide or as a department) to become more data-adept to ensure value for money.
Final Thoughts
As with many business and technical systems, success largely depends on human factors: clear communication, trust and robust well-adopted processes.
Producing dashboards that drive decisions demands strong stakeholder engagement and data culture, clear ownership and accountability, effective data governance and a willingness to challenge requests that will not deliver value. Treating dashboards as internal products (user research, curated launch, success criteria and post-release measurement) materially improves outcomes. Implement the measures described in this article and you will generate decision systems that deliver business impact.
At Lighthouse Data Analytics, we help organisations move beyond dashboard delivery towards analytics that consistently influence decisions. This typically involves stakeholder discovery, data governance, architectural optimisation and adoption-focused rollout strategies.
For more details on how we can help you realise maximum value from your data, do follow us on LinkedIn or visit our website.
