In organisations today, data has never been more available. Dashboards and performance decks exist for almost every function — sales, product, marketing, operations — and the tools to build them have never been more accessible. And yet, in weekly standups and quarterly reviews, the same thing happens constantly: someone shares the numbers, the room nods, and the meeting ends without a decision or clear direction.
When that happens, the data usually takes the blame. The numbers weren’t granular enough, the dataset wasn’t complete, we need more information before we can act. But the data is almost never the problem. The reality is that nobody designed it to deliver insights. The chart was built from what was available, not from the question that needed answering. The audience was assumed rather than understood, and what should actually change as a result of seeing this data — that question — was never asked at all.
Data visualisation and UX are solving the same underlying problem: both are trying to move the right information to the right person in a way that changes something. The vocabulary is different, but the underlying challenge is identical, and the moment you start treating them as complementary disciplines is the moment dashboards stop being a passive collection of charts and start doing something functional.
For designers who work with data, analysts who present to non-technical audiences, and marketers who need their numbers to do more than sit in a slide, this read is for you.
The Chart Was Never The Whole StoryIn 1973, the statistician Francis Anscombe (PDF) published a paper that made a quiet but clarifying point. He constructed four datasets that are statistically identical: same mean, same variance, same correlation coefficient, and same regression line. Run the numbers on any of them, and they are identical. Plot them, and they could not be more different.
Anscombe’s lesson to statisticians was about diagnosis: visualisation reveals the operational truth that raw numbers conceal.
But visualisation isn’t just diagnostic; it is also communicative. The form you choose is where understanding either emerges or gets lost in the noise. Does your audience walk away with numbers, or with a story they’ll quote and talk about?
One of the most striking examples is Visual Capitalist’s History of Pandemics. Instead of burying the reader in a massive data table of casualty counts, it maps the death toll of major historical pandemics using a proportional bubble layout on a single timeline.
Before your brain reads a single number, your visual system grasps the sheer scale of the Black Death relative to everything else on the page. The right visualisation does not just plot the data but makes the story impossible to miss.
Edward Tufte codified a foundational principle for the craft with his data-ink ratio: every mark on a chart should serve the data, not decorate it. It remains a widely used framework in data visualisation, anchored in the assumption that clarity and visual hygiene are the goal.
For a chart in isolation, that holds. But a chart is never read in isolation: it’s read by a person, in a specific context, under specific pressure. Strip a chart down to its cleanest form, and you might be removing the exact layer of context a decision-maker needs. Simplicity isn’t the goal in itself; appropriate complexity is.
Data is a message, and the right amount of signal depends entirely on who’s receiving it.
Which leads to the core principle of data UX: roughly 80% of the work that determines whether a dashboard succeeds happens before you ever draw a chart.
That dependency is the thread the rest of this piece pulls on.
The 80% That Happens Before The ChartThe high-leverage 80% almost never happens on screen. It happens upstream: before a tool is opened, before a dataset is pulled, before a single design choice is made. It comes down to three questions, and once they become habitual, they change what you notice, what you ask, and what you push back on at the outset of every project.
- Context: What are we trying to show with this data?
This is where you define what the visualisations actually need to serve before you touch any raw data. Writing down the precise operational questions, specifically enough to determine what gets pulled and what gets filtered, is what produces a dashboard that helps with decision-making. - Audience: Who is this for, and how do they think?
This is the empathy step. Knowing who’s in the room, what they’re accountable for, and how they engage with data determines how much complexity the visualisation can carry, and how it should be presented. - Insight: What should change once this data lands?
A decision, a new direction, a shift in understanding. If the intended strategic outcome isn’t clear during the design phase, it will remain invisible once the dashboard goes live.
Most data-heavy projects start backward: teams pull whatever metrics their internal analytics tools already track and build visualisations around them, while the question the data was supposed to answer either gets assumed or never gets asked. This happens simply because we anchor on the data in front of us as the boundary of what’s possible.
Defining a goal first sounds obvious, but in practice, it rarely happens with the necessary clarity. “Show me how the product is performing” is not a goal; “Identify which features drive retention among users who signed up in Q1” is, as it includes three things the first doesn’t: a metric, a population, and an implied action. That specificity is what converts an open-ended exploration into a constrained, answerable design problem. Which one you start from determines everything that follows: what you include, what comparisons matter, and what you leave out entirely.
Starting with available data produces a dashboard that answers no particular question, because it was never built for one — every number is present, none of them pointed anywhere. Starting with the operational question does the reverse: every element on the screen earns its place, because each one is there to help answer it.
For example, consider a UX team trying to fix a leaky checkout flow for an e-commerce website. A data-first approach pulls everything available, from clicks to scroll depth and device types, yielding a massive dashboard that leaves everyone asking, “Okay, but what do we actually change?” A context-first approach starts with a constraint: “At which step of the checkout do users drop off?” By filtering out 90% of the noise, the team builds a simple funnel chart, instantly spots a bottleneck on the payment screen, and knows exactly what to redesign.
Audience: Who Is This For, And How Do They Think?Designing for an audience comes down to two things: accountability and familiarity.
Familiarity is about data literacy. Do they read charts instinctively, or does a complex visualisation create friction? Handing a dense, multi-layered dashboard to a Head of Sales and a senior analyst is like giving the same map to someone who navigates by landmarks and someone who reads grid coordinates. The data is accurate, but it is only functional for one of them.
Accountability dictates how that complexity must be presented. A chart showing a 12% decline carries vastly different weight for the executive responsible for that number versus the analyst simply reporting it. Understanding your audience means grasping this relationship; data is never processed neutrally when your performance is on the line.
Together, familiarity and accountability decide one practical thing: how much you can put in front of someone.
In data visualisation, simplicity is not a fixed virtue — the right level of it is contingent on who is reading, and what they need to do.
An analyst relies on a high-density environment to conduct diagnostic discovery. By isolating individual behaviour nodes and mapping out raw user flows, they interrogate the data at its atomic level to uncover the hidden insights and underperforming spend that will shape future campaigns.
An executive, by contrast, requires a highly synthesised translation of that data to immediately identify what is driving commercial growth. Tailoring a dashboard to your audience means adjusting the density dial, delivering maximum signal with appropriate complexity for the specific brain in the room.
Insight: What Should Change Once This Data Lands?Most data projects operate on the comfortable assumption that if a chart is accurate and clear, the insight will take care of itself. In reality, information and insight are entirely different states. Information is what the data shows, whereas insight is the specific decision, shift in understanding, or course correction someone makes as a result of seeing it. If the intended business change isn’t defined before the design begins, a dashboard will default to passive reporting rather than driving action.
Marketing and engineering teams experience the danger of this gap whenever a core business metric suddenly plummets.
A dashboard built for information simply sounds the alarm, showing a chart that tracks a sharp 15% drop in booking rates. Because the data lacks depth, leadership defaults to panic: they immediately call the UX design team, assuming the app is broken or the checkout flow is flawed. Because the data doesn’t pinpoint the core of the problem, it triggers a costly, misplaced fire drill.
A dashboard built for insight isolates the variables required to make an informed decision. Instead of a single, flat booking metric, the visualisation maps the drop against traffic sources and campaign launches — instantly revealing that while app performance and core user conversion are perfectly stable, the sitewide rate was artificially diluted by a massive influx of low-intent click traffic from a newly scaled campaign. The team doesn’t waste time redesigning a functioning app; they get the exact insight needed to pause the underperforming marketing campaign and adjust their acquisition strategy.
Every visualisation implies a next step, even if that step is “nothing needs to change right now.” The question is whether the design makes that implication clear enough for the viewer to recognise it.
From Questions To Dashboard: A Project Walk-throughMy aha moment in data visualisation happened during a project for a client-facing B2B SaaS platform focused on enterprise talent management and competency tracking in Pegasystems skills. The platform captured a massive footprint of daily telemetry, and the brief arrived open-ended: “We have an immense archive of user activity, now we need to present it to enterprise teams.”
We could very easily have charted everything that was captured, but we wouldn’t be doing end users any favours if they just ended up looking at a data graveyard. My responsibility immediately moved beyond pure interface craftsmanship; it became about architecting a highly practical tool for real people who would open this dashboard routinely and need it to tell them an honest, immediate story about their workflows.
Here is how the project actually went.
Context
The client believed this massive pool of data could help their users perform better, and wanted an interface that finally enabled that growth. Translating that broad ambition into tangible visualisations required defining the practical mechanics of performance. What variables indicate advancement vs passive usage? What does “perform better” actually mean? How do you measure it?
An obvious candidate was time spent by product. Every platform tracks it. It is easy to show, and it feels meaningful. But time spent is a proxy; it tells you someone was there, not whether they got anything out of it.
The more meaningful signals were competency scores by area, certification completion rates, and historical performance trajectories. Integrating time-spent data alongside these performance metrics added a useful layer of interpretation, helping us surface which modules users were underutilising and whether that directly correlated with lagging scores. Time spent became a supporting signal in the larger story.
The second question was about the appropriate level of granularity. An identical metric carries completely different weight depending on who is looking at it. An individual contributor tracking their own completion rate needs to know if they are pacing correctly, whereas a manager reviewing a team aggregate needs to know precisely who requires immediate support. This distinction shaped every subsequent data-exposure and filtering decision. Defining that structural story early determined exactly what to show, and to whom.
Audience
The most straightforward approach to this design would have been predictable: use the same charts, but offer an individual view and an aggregated team view. Far too many dashboards rely on this shortcut, subtly tweaking the scale of identical data visualisations and labelling it “personalisation.”
An authentic analysis of the audience reveals a much deeper rift. Frontline team leads and individual contributors required distinct narrative structures and design principles.
Having used e-learning platforms myself, I remember the frustration of opening a tool without a clear sense of my current standing, core strengths, or slipping metrics. That personal experience directly guided the individual contributor workspace; it needed to act as a highly tailored, self-directed mirror that was granular, honest, and personal.
Conversely, the manager’s interface had to bypass individual milestones initially to provide a macro pulse check on team vulnerabilities. It was designed around a different operational reality: how is the group progressing, and where are the consistent gaps? The view prioritised the aggregate picture first, while retaining an intuitive path to drill down into tactical day-to-day coordination when needed.
Insight
Our insight strategy was locked in during the early conceptual phase, long before wireframing a single chart. We intentionally abandoned the idea of building a dense, passive data log and focused on pacing the narrative arc.
For individual contributors, the core value was self-direction, ensuring they could glance at the interface on a Monday morning and immediately derive a clear priority list for the week ahead.
For managers, the goal was to fundamentally shift the timing of operational conversations, providing them with the necessary baseline to intervene before a skill gap evolved into a critical project failure. The visualisations needed to surface the exact moments when a human check-in would be useful, shifting their workflow from reactive post-mortems to proactive guidance.
The comparison tool was the highlight nobody had asked for. A manager dashboard and an individual dashboard are easy to anticipate. What is harder to land is: what if a manager wants to compare two specific team members against the same metrics, side by side? That view came from a design assumption, and it turned out to be the feature that resonated most.
The decisions that mattered most in this project weren’t in the initial brief — capturing data they hadn’t thought to request, and structuring it to answer questions they had not previously known how to articulate, which is the core differentiator of a user-centric data strategy.
Designing The Mental Model Early
The choice of visualisation layout must follow the geometric nature of the data itself. For this project, the core design problem was enabling an individual user to answer a specific question at a single glance: across eight distinct competency areas, where are my relative strengths and gaps?
To solve this, we mapped the data using a radar chart. By organising multiple variables across axes radiating from a central point using polar coordinates, the interface connects the data points to form a single, unified shape. An even, balanced polygon instantly signals well-rounded proficiency, while a sharply skewed shape draws the eye immediately to an outlier area.
While a traditional linear bar chart would have forced the viewer to scan eight individual bars and mentally calculate the variance, a concentric, radial layout segments the data layers to make progress tracking and skill gaps immediately readable. When all dimensions share an identical scale and scoring method, the radar chart is not an unconventional aesthetic choice — it is the most functional tool for multi-dimensional analysis.
The colour system was the other decision made early, and I mean early. During the branding exercise, each of the three products was assigned a colour. That colour did not stay in the brand guidelines. It was built into the data model from the beginning, running consistently across every chart, every filter, every breakdown. By the time a user landed on the dashboard for the first time, the mental model was already in place. They had not been taught the language. They already knew it.
What Changed
The shift from passive information to active insight showed up first in how the dashboard was actually used. Following the deployment of the personalised dashboards and side-by-side team comparison tools, weekly active engagement on the platform’s analytics features rose noticeably, per internally reported figures. Managers were no longer opening the tool once a month to pull static reports. They were using it every Monday morning to actively plan their week.
Revenue and user growth also moved in the right direction over the following two quarters, though — as with most single-project outcomes — it’s hard to isolate the dashboard’s exact contribution from everything else that changed at the same time. The client reported churn across the platform falling to one of its lowest points on record. The clearest evidence of impact came from qualitative feedback. Managers reported that instead of using data to dissect a ‘bad’ month after the fact, the visualisations allowed them to instantly spot slipping performance and schedule a quick supportive catch-up before it turned into a real gap.
ClosingData design reaches its full potential when visual presentation is treated as an upstream architectural choice rather than a downstream formatting step. Bringing structured UX thinking to data turns visualisations into active decision-making engines, ensuring every chart, report, and metric directly serves a human purpose:
- Upstream framing: Grounding every visual choice in a specific operational question rather than defaulting to available metrics.
- Calibrated density: Tuning the level of complexity directly to the literacy and accountability of the specific reader.
- Decision-driven insight: Structuring data to reveal strategic outcomes rather than isolated stats, turning visual signals into immediate operational momentum.
The next time you are tasked with creating a data visualisation — whether it is an enterprise dashboard, an executive report, or a public-facing infographic — step away from the design canvas and BI tools. Focus your initial effort on the human decisions behind the screen. Only then will your data stop being a passive log of the past and start driving the direction of the future.