Dashboards and Data Storytelling Get a UX Reckoning

The dashboard on your screen right now is probably correct and useless at the same time. It shows the right numbers, the room nods, and the meeting ends with no decision. That gap is getting attention this month, and the fix runs deeper than picking a better chart. Let me catch you up.

The deep cut

• A dashboard exists to change a decision. Meriem Benhabiles says the meeting ends without direction because nobody designed the chart to answer a question.
• Do the thinking before you draw the chart. Roughly 80% of what makes a dashboard land happens before any tool opens.
• The model under the chart is the product. Point an agent at raw tables and it guesses whether revenue means the transaction or the commission.

The chart is not the job

A clean chart is not the same as a useful one. In Smashing Magazine, Benhabiles points to Anscombe's Quartet: four datasets with identical stats that look completely different once you plot them. The numbers hid the truth. The picture showed it.

But the picture only works if it answers a real question. Benhabiles argues that "roughly 80% of the work that determines whether a dashboard succeeds happens before you ever draw a chart." The work is three questions asked upfront: what are we trying to show, who is this for, and what should change once they see it. Skip those and you build from what your tools already track, not from what anyone needed to know.

Same map, wrong reader

Density is not a virtue on its own. A Head of Sales and a senior analyst can look at the same dashboard and only one of them can use it. Benhabiles frames this as two dials: familiarity, meaning how fluently someone reads charts, and accountability, meaning whose number is on the line. A 12% decline lands differently on the executive who owns it than on the analyst reporting it.

Her checkout example makes the tradeoff concrete. A data-first team pulls clicks, scroll depth, and device types into a wall of charts, and everyone asks what to change. A context-first team starts with one constraint, "at which step do users drop off," filters out 90% of the noise, and spots the payment-screen bottleneck. Same data. One of them drives a redesign.

The layer nobody sells

Here is where the enterprise crowd catches up to the same idea from a different door. The Towards AI piece argues that the "talk to your data" agent everyone is shipping is packaging. What decides whether it works is the modeling layer underneath, the tables where joins, grain, and definitions were settled years before anyone said the word agent.

The vendor pitch is usually the context layer, the markdown and column descriptions that get you to a demo in an afternoon. That layer helps. It does not replace the two under it. Point an agent at raw tables and it guesses at every business definition: does revenue mean the transaction or the commission, do reversals count, which processor rate applies. In a payments business, the author notes, an agent can return gross transaction value instead of revenue, off by two orders of magnitude, and still hand you a clean, confident number.

Why the throttle disappeared

Before AI, the analyst writing the query was the rate limiter. Asking cost time, so people asked less, and that friction quietly covered for gaps in the model. Remove the human and three things move at once: volume up, per-query quality down, and run-to-run variance up. The same question, asked twice, takes two paths to two numbers.

So modeling matters more now, not less. This is the trust gap QueryStory is selling against. CEO Shapor Naghibzadeh warns that when hundreds of people ask a chat UI their own questions, "you just end up with this huge sprawl of content, and there's no real place to hang that content that ties back to the data." His fix surfaces the SQL and a confidence indicator so a decision-maker can see why the machine believes its own answer. Same lesson as the chart and the model: the surface is only as good as the thinking behind it.

Three questions for your team

• Before we build the next dashboard, can we write the one operational question it answers, with a metric, a population, and an implied action? If not, we are charting what our tools track, not what we need.
• Who is this for, and does its density match their job? Are we handing an executive an analyst's diagnostic graph and calling it done?
• If we plug an AI agent into our data, what does "revenue" resolve to, and did a person settle that in the model, or is the agent guessing every run?