Why No One Reads Your Dashboard

I spent last week reading through the IS success literature again, and one number kept bothering me. Torres, Sidorova, and Jones (2018) found that business intelligence and analytics reaches firm performance through business process change, not through analytical output by itself. Not through the dashboard. Not through the charts. Through the changes those charts enable an organization to make. And I realized this explains something I have been noticing for years: almost every organization I have seen has dashboards, and almost nobody reads them.

The dashboard is the default deliverable of the modern analytics team. A new data warehouse gets built, a BI tool gets licensed, and within three months there is a screen of KPI tiles somewhere on a monitor in an open-plan office. Red, yellow, green. Revenue trending down. Support tickets spiking. The dashboard sits there and the numbers change and nobody acts on them. The next quarter, someone builds another dashboard. The cycle does not stop. The question is not whether the data is accurate. The question is whether the dashboard was designed for reporting or for decision-making, and most of them are designed for the first while pretending to be the second.

DeLone and McLean (1992, 2003) built the IS Success model with six dimensions: system quality, information quality, service quality, use, user satisfaction, and net benefits. The model has feedback loops, use shapes satisfaction and satisfaction shapes future use, but the core insight that carries across decades is that information quality is one of the three quality drivers at the front of the chain. Good information quality leads to use and satisfaction, which together produce net benefits. What DeLone and McLean did not fully specify, because the empirical context was different in 1992, is what information quality actually means when the information is piped into a dashboard that refreshes every fifteen minutes. The 2003 update added service quality as a sixth dimension, capturing the IT support layer, which matters for dashboards because a dashboard without a person who can explain why the number changed is a dashboard that will be ignored after the first three confusing meetings.

Burton-Jones and Grange (2013) gave the field a sharper tool for this problem. They defined effective use as faithful domain representation: using a system in a way that faithfully appropriates the real-world structures the system was designed to represent. Use is not adoption, because adoption is the decision to start. Use is not evaluation, because satisfaction is a judgment about engagement. Use is the behavioral pattern of engagement itself, and effective use happens when that engagement connects to the deep structure of the domain, not just to the surface charts and filters a dashboard provides. A dashboard KPI tile that shows a number changing every hour is surface structure. The deep structure is the operational process that generates the number, the decision rights that determine who can act on it, and the causal logic that connects the number to an outcome an organization cares about. Most dashboard users never reach the deep structure because the dashboard was not designed to take them there.

Torres and Sidorova (2019) extended this logic specifically to business intelligence and analytics. They argued that information quality in BI and A is not a property of the system that can be measured independently of the user. Information quality is constructed in the process of effective use. Their model decomposes BI and A use into three components: transparent interaction, meaning the user can see how the data was derived and what assumptions the system made; representational fidelity, meaning the system faithfully captures the domain it claims to represent; and actionability, meaning the user can translate what they see into a decision. The three components mediate the path from system quality, data quality, and analyst expertise to performance benefits. Information quality is not delivered. It is built, moment by moment, in the interaction between a person and a system. If the dashboard does not support transparent interaction, if the user cannot tell where the number came from, the dashboard will not produce effective use. If the representation does not match the operational reality the user deals with every day, the dashboard will not produce effective use. If the user cannot act on what they see, the dashboard will not produce effective use.

I think this is the real reason dashboards fail. The typical dashboard project starts with a data question. What is our revenue this quarter? How many tickets did we close? The team connects the source, builds the pipeline, and designs the visualization. The deployment meeting happens. The dashboard goes live. And then nothing changes, because nobody asked the decision question. What decision will this number inform? Who will make that decision? What other information do they need alongside this number to act confidently? The dashboard was built as a reporting artifact, a window into a database, when it should have been built as a decision artifact, a tool that helps a person engage the deep structure of their domain.

Torres, Sidorova, and Jones (2018) make this concrete in a different way. They frame BI and A as the sensing and seizing components of dynamic capabilities. Sensing means scanning the environment for opportunities and threats. Seizing means mobilizing resources to capture value from what was sensed. A dashboard serves sensing. It tells you something changed. But sensing without seizing produces nothing. The analytics team can build the most elegant dashboard on the market, but if the organization cannot change its business processes in response to what the dashboard reveals, the investment is wasted. The authors showed empirically that BI and A reaches firm performance through business process change capabilities, not through analytical output by itself. The dashboard that cannot trigger process change is a decoration.

I have seen this pattern in healthcare specifically. Two hospitals buy the same electronic health record system, run the same analytics module, and generate the same quality dashboards. One hospital uses the dashboard to identify that its emergency department wait times are driven by lab result delays at a specific shift handoff, changes the handoff protocol, and reduces wait times by thirty percent. The other hospital looks at the same dashboard, confirms that wait times are high, and does nothing because nobody has the authority or the process mandate to act on the numbers. Same data, same dashboard, different outcomes. The difference is not the technology. The difference is whether the dashboard was embedded in a decision process that could act on the information it produced.

I wrote about effective use before, about how Burton-Jones and Grange changed the question from how much people use a system to how well they use it. And I wrote about the productivity paradox, about how IT investment does not produce returns until organizations restructure around it. This dashboard problem is the same pattern at a smaller scale. The analytics dashboard that sits untouched is the productivity paradox in miniature. The investment is measurable. The software license, the data engineering hours, the monthly maintenance cost. And the return is invisible because no return was ever produced.

The fix is not a better visualization library. It is not a faster data pipeline or an AI-generated narrative summary. The fix is to start with the decision. Before you build a single KPI tile, ask who will act on this number, what they need to know alongside it, and what process change the number is meant to trigger. If you cannot trace the dashboard to a specific decision that a specific person will make differently, the dashboard will not be read. DeLone and McLean gave us the framework to understand why: information quality sits at the front of the success chain, but information quality is not a property of the database. It is a property of the use.