Why Your Dashboard Isn't Driving Decisions
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. 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. 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.
The 80% That Happens Before The Chart
The 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:
1. Context: What are we trying to show with this data?
Define what the visualisations actually need to serve before touching raw data. Write down precise operational questions — specific enough to determine what gets pulled and what gets filtered. For example, instead of "Show me how the product is performing," ask "Identify which features drive retention among users who signed up in Q1." This includes a metric, a population, and an implied action.
2. Audience: Who is this for, and how do they think?
Know who's in the room, what they're accountable for, and how they engage with data. This determines how much complexity the visualisation can carry. An analyst needs high-density environments for diagnostic discovery. An executive requires a synthesised translation that highlights commercial growth. Adjust the density dial accordingly.
3. Insight: What should change once this data lands?
Define the intended strategic outcome before design begins. A dashboard built for information just sounds the alarm when a metric drops. A dashboard built for insight isolates the variables needed to make an informed decision. For example, a sudden 15% drop in booking rates might be traced to a new marketing campaign bringing low-intent traffic, not a broken app.
# Example: Defining context, audience, and insight before building a dashboard
context = "Which features drive retention among Q1 signups?"
audience = "Product manager, data-literate but time-poor"
insight = "Prioritize features to improve for next quarter"
# Hypothetical data pull - only relevant metrics
data = get_metrics(
features=["onboarding_completion", "daily_active_users"],
cohort="Q1_signups",
time_range="last_90_days"
)
# Design decision: simple bar chart for comparison, not complex scatter plot
chart = create_chart(data, type="bar")
A Project Walk-through: From Questions To Dashboard
During a project for a B2B SaaS platform focused on enterprise talent management, the brief was open-ended: "We have an immense archive of user activity, now we need to present it to enterprise teams." Charting everything would have created a data graveyard. Instead, the team focused on the three questions.
Context: The goal was to improve user performance. Time spent is a proxy metric; more meaningful signals were competency scores, certification completion rates, and performance trajectories. Time spent became a supporting signal.
Audience: Individual contributors needed a self-directed mirror showing strengths and gaps. Managers needed a macro pulse check on team vulnerabilities with drill-down capability. This led to distinct dashboards, not just scaled versions of the same charts.
Insight: The goal was to shift managers from reactive post-mortems to proactive guidance. A side-by-side team comparison tool became the most resonant feature.
The Power of the Radar Chart
For individual contributors, we used a radar chart to map eight competency areas. An even polygon signals balanced proficiency; a skewed shape highlights gaps. This is more effective than a bar chart for multi-dimensional analysis with a shared scale.
The Mental Model and Color System
Each product was assigned a color during branding. This color was built into the data model from the beginning, running consistently across every chart, filter, and breakdown. Users didn't need to be taught the language; they already knew it.
Closing: From Passive Logs to Active Decisions
Data design reaches its full potential when visual presentation is treated as an upstream architectural choice rather than a downstream formatting step. Key principles:
- Upstream framing: Ground every visual choice in a specific operational question.
- Calibrated density: Tune complexity to the reader's literacy and accountability.
- Decision-driven insight: Structure data to reveal strategic outcomes, not isolated stats.
For designers, analysts, and marketers, this approach turns dashboards into engines for change. Start with the human decisions behind the screen, and your data will drive future direction.
Limitations and Considerations
This approach requires upfront investment in stakeholder interviews and question definition, which can be time-consuming. It also demands data literacy from the design team. Over-simplification for executives risks losing nuance, while over-complexity for analysts can hinder quick insights. Balance is key.
Next Steps for Learning
Dive deeper into UX research methods for understanding audience needs, explore advanced chart types for specific data questions, and study case studies of successful dashboard redesigns. Practice by applying the three questions to a dashboard you use daily.
For more on building practical tools, check out this guide on building AI agents with ADK for Kotlin & Android. Also, explore the latest React Foundation launch under the Linux Foundation for insights on community-driven development.
Source: Rethinking Data Visualisation: A UX Approach To Dashboards