You may already know about dashboard fatigue. If not, you’ve certainly felt it. Dashboard fatigue is typically defined as the headache and eventual numbness that results from spending too much time staring at reports/dashboards and trying to understand their content. (Note: While you can technically distinguish between the reports and dashboards, I’ll be using the terms interchangeably in this post). The overexposure to all that information is comparable to quicksand: the more you try to figure out what you’re looking at, the more confused and tired you become. This definition of dashboard fatigue is usually oriented towards business stakeholders.
In reality, the struggles of business stakeholders and their dashboards are only the tip of the dashboard fatigue iceberg. The nightmare of dashboard fatigue runs much deeper within the organization, plaguing more aspects of the organization than one might imagine.
The Two Types of Dashboard Fatigue
Data Analyst Dashboard Fatigue
Data analysts are arguably the biggest sufferers of dashboard fatigue. In fact, their dashboard fatigue is enveloped in a vicious cross-organizational fatigue cycle (but we’ll get to that later). Analysts’ dashboard fatigue doesn’t stem from overexposure to staring at dashboards, but rather continuously building and servicing them.
Today, building and servicing a dashboard is a wildly inefficient process. We have to make sure we’re transforming the right data for the report, then we have to build a report to present the data. Once it’s all formatted, designed, and presented in an “easily digestible” form (yes, at times we need to spoon-feed our stakeholders), then we have to service the business stakeholders. We need to explain how to use the dashboard and its content, execute any changes or “service requests” on the report, communicate those changes back to the business stakeholders, clarify any confusing details, and answer a new set of questions about the data and insights. Finally, we hope a new request doesn’t come in, too soon.
But a new request always does come in, really soon. Data analysts are confined to a never-ending feedback loop of “Is this the most recent version of these metrics?” and “How do I get my answer from this dashboard?” and “How is this number being calculated?” and “What does this number mean?” and… well, you know the rest. It’s a fatiguing purgatory of frequent, repetitive, and, at times, redundant tasks.
Business Stakeholder Dashboard Fatigue
When there are too many dashboards across too many tools, business stakeholders inevitably experience frustration, exhaustion, and confusion (i.e., business stakeholder dashboard fatigue). Spending the entire day trying to navigate dashboards can lead to desensitization to the data presented, avoiding dashboards entirely, or even analysis paralysis - a state where users get overwhelmed with data to the point that they end up not even being able to reach a conclusion. Any of these possibilities become especially consequential when considering how far-reaching a misguided decision can be.
Currently, business stakeholders avoid these dire consequences by reaching out to analysts with requests for clarifications, instructions, and anything else they might be having difficulty with. In other words, hand-holding.
But what happens when these requests take over our real responsibilities (not to mention our promised job descriptions)?
Over time, analysts get so worn down from continuously building, servicing, and clarifying reports that the quality of their output inevitably decreases (how much love can a person put into something that drives them nuts, anyway?). As a result, business stakeholders have more difficulty understanding the reports and submit more requests, effectively joining analysts in a cross-organizational vicious cycle of dashboard fatigue that only gets worse over time.
Data analysts and business stakeholders are not the only ones harmed by dashboard fatigue. The business hurts as well. Because of the sheer number of requests, data teams are forced to play a constant game of catch-up and get quashed to a customer support role, rather than fulfilling their true purpose: being a strategic partner of business stakeholders. At the same time, stakeholders experience long time-to-insights and miss out on the full value of their data teams. As a result, organizations suffer increased costs and withheld growth due to inefficient utilization of resources.
The Sources of Dashboard Fatigue
Dashboard fatigue is effectively a reflection of inefficient work processes and lacking infrastructure within the organization. This can be traced back to three factors:
- Proliferation of dashboards
- Issues with the data model
- Lack of data democratization infrastructure
Proliferation of Dashboards
At first glance, dashboard proliferation may appear to be a positive indicator of an active data-driven organization. In reality, it is an exponential force that overwhelms the organization, business stakeholders, and data analysts alike.
In the past decade, organizations have found themselves competing in the race to become “data-driven.” While this quest is an admirable one, one side-effect is that analysts get flooded with data requests in order to keep up with their business stakeholders’ data-driven decision-making eagerness.
But as much as business stakeholders want to make data-driven decisions, they also have BI-tool/data-phobia. As soon as they hear dashboards are in the mix, palms start sweating, knees get weak, and arms become heavy. This is in no way to fault our business stakeholders, as most don’t have the knowledge necessary to independently operate BI tools and extract insights from dashboards. Consequently, most business stakeholders understandably submit to us “Just give me the answer!” type requests, where the deliverable is a simple report.
This type of request comes at a steep price. Data teams become confined to creating reports that apply to only one narrow use case (the task at hand), rather than building flexible dashboards that simultaneously provide data for additional use cases. And because each report has its own (non-transferable) nuances and context, business stakeholders inevitably hit the request button for yet another new report, inundating our backlog with mundane, repetitive tasks.
Dashboard proliferation is a difficult beast to get a hold of. With a rapidly increasing number of dashboards, dashboards quickly become disorganized and hard to find, which eventually makes them stale and unmaintained, diminishing the company's ability to leverage existing resources.
Issues with the Data Model
The organization’s data model houses codified business logic, which lays the groundwork for reporting and calculating metrics. When there are issues surrounding the data model, the ripple effects lead to difficulties in building a dashboard.
Currently, many organizations’ data models consist of patchworked code and present inconsistencies across key fields. These inconsistencies trickle all the way down to the worst possible outcome: inaccurate or inconsistent reporting of metrics.
Analysts are faced with a lose-lose situation. Whether they use the data from the data model or they calculate their own metrics further downstream at the reporting level, both would almost necessarily lead to future inconsistent reporting as different analysts inevitably employ different logic. In the end, whether we or our business stakeholders get confused because of dashboards presenting different numbers, what awaits us is hours and hours of metrics reconciliation.
Beyond making building and servicing a report incredibly tiring and time-consuming, the noticeable absence of a concrete model also compels analysts and business stakeholders to doubt the reliability of the data.
Lack of Data Democratization Infrastructure
With data democratization came the age of self-service analytics. The promise was that, without having to depend on the data team, business stakeholders would reduce their time-to-insight by analyzing data and creating reports on their own. But are a bunch of Explores/Views/Explorations or drag-and-drop dashboard building functionalities enough to deliver on this promise?
Data democratization requires a holistic approach and appropriate infrastructure. Beyond simply having the ability to access data, our stakeholders need to have a way to easily find, fully understand, and confidently use the data we prepare for them in order to properly extract insights on their own. Without it, business stakeholders will forever ask the same repetitive questions about how to use a dashboard, if a report is up-to-date, how metrics were calculated, where the data come from, etc.
Due to their repetitive and anticipatory nature, these questions should be “taken care of” in advance. Without a level playing field, gaps in trust, knowledge, and context will inevitably arise, resulting in an ever-growing servicing backlog for us and long time-to-insight for them.
The Solution
In order for analysts to receive fewer requests, business stakeholders must be empowered to independently answer questions that extract insights. Achieving “real” self-service requires investment in both the back end (data-team-facing) and front end (business-team-facing) to democratize BI infrastructure.
Back End (Facing the Data Team)
Strengthening the Data Model
The first order of business on the back end is ensuring a robust data model, as this defines the inputs and outputs for decision-making.
Creating a robust data model involves as much strategic thinking as it does writing clean, dynamic, and precise code. Data teams must fully understand the business and the challenges being addressed in order to create a data model reflective of its purpose. Only then can they cement key fields in downstream tables as “sources of truth” for all functions of the data team to orbit around. During the process of building the data model, data teams should also support the model with documentation, which includes descriptions of tables and columns, dependency graphs that visually explain the links between fields, any required tests, and anything else that could help colleagues utilize and debug it.
Centralizing Metrics Repositories
That being said, a robust data model is not enough to deliver consistent numbers and metrics. Data teams should also invest in a central metrics repository that standardizes metrics formulas, ensures accurate definitions, and creates consistent terminology across the entire organization.
The challenge is that organizations move fast and new metrics are constantly being defined. This means there will sometimes be too many permutations or nuances with metrics to be included in the repository, which leads to metrics being calculated in downstream reporting layers (e.g. BI tools).
But data teams must still find a way to record these metrics definitions to track how they are calculated and which dashboards they reside in. This may exist in a separate process, but will help map metrics back to the central repositories and control for reporting inconsistencies.
Standardizing Verification Rules
In addition to driving towards consistent metrics, implementing "verification" rules increases trust in the data. Verifying dashboards and reports promotes better data resource management across data and business teams. As such, "Verified Assets" are assets that have been vetted by the data team, guaranteeing each asset has an owner, is well-maintained, is well-documented with the right context for the business stakeholders (more on that in the next section), and presents consistent metrics. This doesn’t mean that unverified assets should get deleted. They may still be useful for the data team, and should not be freely used (without our supervision) by business stakeholders.
Teams should have standard verification rules (making sure pipelines are working properly, data is correct and properly documented, etc.), as well as a defined interval schedule for re-verification, based on the characteristics of the report (the intended audience, the type of data included, static report/live dashboard, etc.). Making distinctions between verified and unverified dashboard ensures that the organization is consuming data that is "safe" to use, reducing the amount of dashboard servicing and clarification requests hitting our desks.
Front End (Facing the Business Team)
Once dashboards are presenting consistent metrics and being regularly maintained, they need to be both quickly discoverable and easily understandable for business stakeholders.
Enhancing Discoverability
Discoverability is largely dependent on the organization of reports, dashboards, and documentation. This includes formalized folder structures, as well as documentation on where different types of (good-to-be-used) dashboards are saved. This should be defined as a collaborative process across data teams and business stakeholders to align on naming conventions, folder hierarchy, and communication channels. When dashboards become easy to find, load on the data team decreases, stakeholders are happier and can make informed decisions more quickly, existing dashboards get put to maximum use, and the likelihood of redundant requests significantly decreases.
Standardizing Business Stakeholder-Facing Documentation
Data democratization goes beyond enhancing discoverability. For our stakeholders to become truly independent, we need to provide them with the right knowledge and context to properly consume the data. This should be done with business stakeholder-facing documentation.
Unlike documentation for the data model that is for the data team, this documentation is meant for business stakeholders, to help them understand and utilize the dashboard on their own. As such, it should be formatted and written in an easily digestible manner and include as much context as possible about the content. These should be thought of as an instruction manual for using dashboards, and should be packaged with published dashboards.
Documentation should include how stakeholders are to use and consume the dashboard; metric definitions and their purpose (in writing that is clear for the stakeholder); data sources; how to filter for your needs; etc. It should also be easily accessible to business stakeholders. Rather than flooding the dashboard description with information, include a link to a separate GoogleDoc or Confluence page containing the documentation where you can add the context needed in an organized, easy-to-follow fashion.
Centralizing Communication
Beyond enabling stakeholders to find, trust, and understand the dashboard they need, data teams should also centralize any communication with the business team.
Any time the data team works on a task, there is endless back-and-forth with stakeholders. While this back-and-forth can be a pretty grueling process, it is actually incredibly useful for informing future tasks. Valuable context and nuances get exchanged, including insights and edge cases that are being surfaced. If collected and organized, this information can help future users of the assets better understand and use them, which will proactively limit future back-and-forth. This information should be included along with the dashboard by either adding the email/Slack thread or the link to the Monday.com/Asana/Jira ticket.
Scheduling Recrecurrent Deliveries
Finally, identifying repetitive requests (such as sending a business stakeholder the same dashboard over and over again at a specific time) and automating them instead will save time for both data professionals and business stakeholders. Business stakeholders should be able to set scheduled deliveries of reports so that they automatically receive them without having to reach out to the data team. BI tools provide this functionality, but stakeholders often still ask, as they are typically not proficient enough with these tools.
Orchestrating an Ecosystem of Solutions
In the end, having proper data democratization infrastructure is the most effective solution for helping stakeholders with data phobia, increasing trust in the data, and eliminating the majority of stakeholders’ requests.
However, the challenge with data democratization infrastructure goes beyond implementing a framework for how to document dashboards or processes for verification schedules. Going from good to great involves coordinating how these complex, interdependent processes work together. For example, rather than manually following the principles of context-rich documentation outlined above, is there room for a workflow that automatically creates the documentation and schedules a verification reminder, as soon as a dashboard gets completed? The value of a data democratization infrastructure lies in connecting these different types of solutions into one cohesive and efficient workflow.
Faster Time-to-Insight on All Fronts
With today’s increasing data demand, achieving real self-service is not a luxury for data teams, but rather a necessity.
By working on work processes and infrastructure to allow stakeholders to find, trust, and understand the content they need, we can break the vicious cycle of dashboard fatigue.
Business stakeholders become empowered to independently consume trusted data and easily make accurate, data-driven decisions. As a result, analysts become liberated from a purgatory of redundant tasks and finally have the capacity to work on more fulfilling tasks. And finally, the organization flourishes from both teams reaching their full potential by not spending excessive time on inefficient, unscalable, short-term solutions.
Contact us at coffee@hirupert.com to learn how to efficiently scale your BI operation by enabling your stakeholders to independently find, trust, and understand the data they need, whenever they need it.
.
