Walk into any boardroom in a regulated sector and there is a dashboard somewhere. Compliance heat map. Regulatory exposure summary. Risk and assurance overview. The names vary.
The role is the same. It is the artefact someone produced when the regulator started asking harder questions, and the board agreed something visible should exist.
Most of these dashboards are not used. Not in the sense nobody opens them. In the sense no decision is ever made because of one. The board pack still drives the conversation. The dashboard sits in a tab nobody clicks during the meeting.
I have built data products for boards. I have also watched boards receive them and quietly route around them. The pattern is consistent enough to be a design problem, not a literacy problem.
What boards do with data
A board meeting runs to a clock. Six items, three hours, fifteen people, half of whom have read the pack on the train. The chair has a sequence and an outcome they need by lunch. Each agenda item closes with a decision, an action, or a deferred question.
The dashboards which work in this environment have a specific shape. They tell the board what changed since last time, what is now at risk, and which decision the board is being asked to make. Three things. The visual surface is whatever lets a senior executive read those three things in under thirty seconds.
The dashboards which fail are the ones built around the data model rather than the meeting. Twelve KPIs, a colour-coded grid, a regional drill-down. The information is correct.
The structure assumes the reader has time to navigate it. The reader does not. The reader has eight minutes between coffee and the next item.
This is a context failure, not a sophistication failure. The product was designed for someone who had time to explore. The user has time to act.
Why this happens
The teams who build board-level dashboards are the teams closest to the data. They report to the CDO, the CIO, or the head of business intelligence. They are good at structure, accuracy, and lineage. They are rarely in the boardroom.
The brief they receive is normally an intermediated one. The CRO's chief of staff describes what the board wants. The CDO's team interprets the description. The dashboard is built to the interpretation. By the time the artefact reaches the board, it has passed through three filters which none of the actual users have set.
A second compounding factor. The people commissioning the dashboard are usually not the ones using it. The brief is written by a head of risk who wants reassurance the regulatory question is being managed. The user is the chair of the audit committee who needs to challenge it.
The first wants comfort. The second wants disconfirmation. A dashboard built for the first cannot serve the second.
The result is an artefact which does an excellent job of the wrong job. Internal teams see it as evidence the regulator is being addressed. Boards see it as evidence the team is doing something. Neither group is wrong. Neither is using the dashboard to make a decision.
What changes when the design changes
I built a tool last year, ScoreView, which took social housing case data from the Housing Ombudsman and presented it to provider boards. The first version had everything you would expect. Open cases, average resolution time, severity bands, year-on-year trend, drill-down to property. It tested badly.
The second version had three things on the front page. What is new since the last meeting. What looks like it is becoming a pattern. Which decisions the board is being asked to make at the next meeting.
The drill-down still existed. It moved off the front. The board members who had ignored the first version began bringing the second one to meetings and using it to challenge management.
The data was the same. The structure was the same. The presentation surface had been reorganised around what the user does in the room rather than what the data team had to show.
The transferable lesson has nothing to do with housing or ombudsman cases. It is the inversion the team building the product has to make. Design from the meeting backwards. Not from the data forwards.
What boards should ask before commissioning the next one
Three questions, each short, each capable of redirecting the spend.
The first is who, by name, will use this product in a meeting, and what decision they will make with it. If the answer is a role rather than a person, the brief is not specific enough. If the answer is no decision, the product is reporting, not decision-support, and should be costed accordingly.
The second is what gets removed when this product is introduced. Boards already drown in artefacts. A new dashboard which adds to the stack rather than replacing something is a net cost, no matter how good it is. The good dashboards displace existing reports. The bad ones add to them.
The third is who has tested this with a board member, in a meeting context, before live release. Not in a demo. In a meeting where the board member had to use it to challenge a real recommendation. If the answer is no one, the product has not been tested for its actual use.
These are not data questions. They are product questions. They sit with the executive sponsor, not the technology directorate. The most expensive thing a board does with regulatory data is commission a beautiful product which fails to change a single decision.
The dashboard is not the deliverable. The decision is.