Your Users Cannot Read the Report You Just Built for Them
I have watched a plant manager open a report he asked for by name, study it for four seconds, and reach for his spreadsheet. The report was correct. The numbers reconciled. He still could not read it.
Not because he was slow. He runs a facility with a few hundred people. He reads a P&L and a shift roster without help. What he could not read was a variance chart with a reference band. Nobody had ever shown him that the grey band meant "expected range," or that the dot outside it meant "look here first."
You have built that report. Most of us have. You picked the right visual, labelled the axes, and passed every technical review. Then the person it was built for opened it once and went back to the export they already trusted. You never heard why. Months later someone called the report "too complicated," and you assumed they meant the data.
They did not mean the data. They meant the grammar. A waterfall, a small multiple, a trend with a confidence band: these are a language. Fluency is not automatic. We forget that because we became fluent so long ago we no longer remember learning it.
Here is what most BI work gets backwards. We assess the data before we build. We check the sources, the refresh, the security model. We almost never assess the reader. We treat literacy as a training problem to solve after go-live, when it was a design input we needed before the first visual.
The numbers are not subtle. In DataCamp's 2026 survey, 88% of organisations said basic data literacy matters for daily work. Inside their own walls, 60% reported a real skills gap. Years earlier, Qlik and Accenture found only 32% of people could produce measurable value from data. Another 36% worked around the analytics tools they were given. That 36% is your abandoned report. It had a face and a name before it became a statistic.
We do not deliver software to a machine without checking it has the memory to run. We check the environment first. A report is the same. The environment is the reader. If the audience cannot decode a variance chart, the variance chart is the wrong deliverable for them, however correct it is.
This is not an argument for dumbing things down. It is an argument for matching the format to the fluency in the room. The same number becomes one framed value for the executive who wants the answer. It becomes an exploration view for the analyst who wants to interrogate it. It becomes a plain table for the manager who trusts rows more than shapes. One truth. Three grammars. You choose which one a person gets by knowing what they can read, not by guessing.
The assessment is quick. Ninety minutes with the real users tells you more than any requirements workshop. You watch them read three sample views and say aloud what they think each one means. You learn which conventions land, which ones need a legend, and which ones you should not use at all with this audience. That is a design input. It belongs before the build, next to the data source map.
If you are about to hand over a report, do one thing first. Sit with two or three of the people who will actually open it and ask them to narrate what they see. Not whether they like it. What it means. The silences will show you where the report fails, and the silences are recoverable while it is still a draft.
If you inherited a report nobody uses, resist the urge to rebuild the visuals. Check first whether anyone ever verified the audience could read them. Often the model is fine and the data is fine. The mismatch is between the format and the fluency, and that is faster to resolve than a rebuild.
A report built for readers who cannot interpret a variance chart is not a reporting failure. It is a delivery failure that happened before the first visual was drawn. Most organisations that name literacy as their barrier are not short of tools. They are short of a ninety-minute assessment that would have told them which users can read the report and which ones need a different format. Run the literacy assessment before you build, not after adoption stalls. → Run the literacy assessment
Run the literacy assessment.
A report built for users who cannot read a variance chart is not a reporting failure. It is a delivery failure that happened before the first visual was drawn. A literacy assessment tells you which users can read the report and which need a different format, before you build, while the format is still a choice.
Book a 30-Minute Discovery CallFrequently asked questions
How is a data literacy assessment different from user training?
Training happens after the report exists and tries to lift the reader up to the design. An assessment happens before, and lowers the design to the reader where needed. Training assumes the format is fixed. Assessment treats the format as the variable and the reader as the constant. You want both, in that order.
We already gathered requirements. Does that not cover the audience?
Requirements capture what people want to see. Literacy captures what they can decode once they see it. A stakeholder can ask for margin by region and still be unable to read the diverging colour scale you chose to show it. That gap sits between the request and the reading, and requirements workshops never look there.
Is low data literacy the user's problem or the builder's?
It is neither party's fault and both parties' problem. The user is not obliged to learn your visual conventions. You are not obliged to strip every report to a table. The resolution is a format matched to the audience, decided on purpose. Treating it as the user's failing is how reports end up abandoned in silence.
What does the assessment actually look at?
It watches real users read a small set of sample views and say aloud what each one means. It records where interpretation breaks: an unlabelled reference band, a chart type they have never met, a colour that carries no meaning for them. The output is a short map of which formats this audience reads unaided, which need a legend, and which to avoid. That map becomes a build input.