Here’s something that happens all the time: Someone spends three weeks building a beautiful dashboard. Multiple tabs, interactive filters, clean design, automatic data refresh. They send it out with pride.
Two months later, they check the usage logs. Five people have opened it. Three of them opened it once and never came back.
That dashboard is now digital graveyard material. It sits there, refreshing daily, serving nobody.
This happens so often it’s almost the default outcome. And it’s not because the dashboards are poorly built. It’s because the wrong questions were asked before building started.
Most people jump straight into: “What charts should I include?” or “Should I use Tableau or Power BI?”
Those questions come later. Way later.
Here are the questions you should actually ask first.
Not “who might find this interesting.” Who will actually open this thing regularly?
Bad answer: “The marketing team.”
Better answer: “Sarah, the paid ads manager, and her boss Tom who reviews campaign performance weekly.”
Get specific. Names. Roles. Not departments.
Why this matters: A dashboard for “the marketing team” tries to serve everyone and ends up serving no one. Different people need different things. The intern running daily reports needs different views than the VP making budget decisions.
What to ask:
Who is the primary user? (One person or role)
Who are secondary users? (If any)
What’s their data literacy level?
How much time will they spend on this?
Are they looking at this on desktop or mobile?
A dashboard for a VP should be high-level, fast to scan, and focused on trends and exceptions. A dashboard for an analyst should be detailed, filterable, and drill-down capable.
If you can’t name specific people who will use this, stop. You’re probably building something nobody asked for.
Btw, over the last few months, I’ve noticed something: AI is shipping code faster than ever, but when something breaks in production, it’s still humans scrambling to debug decisions they never made.
That’s the problem with AI-generated code. Speed is dangerous without visibility.
Honeycomb solves this with high-cardinality observability: trace issues across user_id, rollout version, or deployment timestamp in real time. The clarity you actually need when code changes daily.
Charity Majors breaks down why this matters → https://fandf.co/3XGhQeL
(Sponsored)
Dashboards should drive decisions. If nobody is making decisions based on this data, it’s just pretty charts.
Bad answer: “It helps people understand our performance.”
Better answer: “Sarah uses this every Monday to decide which ad campaigns to pause, which to scale up, and where to shift budget.”
That’s a specific decision. Now you know what data matters.
What to ask:
What specific decision will someone make using this?
How often do they make this decision?
What happens if they make the wrong decision?
What data do they need to make it confidently?
Example decision-based dashboards:
Inventory manager dashboard:
Decision: What products to reorder this week
Needs: Current stock levels, sales velocity, lead times, stockout risk
Doesn’t need: Last year’s trends, customer demographics, sales by region
Customer success dashboard:
Decision: Which accounts need immediate attention
Needs: Health scores, usage trends, support tickets, contract renewal dates
Doesn’t need: Total revenue, new customer acquisition, marketing metrics
Sales manager dashboard:
Decision: Which deals to focus on this week
Needs: Pipeline by stage, deal age, close probability, rep activity
Doesn’t need: Historical win rates, product mix, customer satisfaction scores
Notice how specific these are? Each dashboard has a clear purpose. You can immediately tell what belongs and what doesn’t.
If the answer to “what decision does this support” is vague or turns into a list of 10 different things, you’re building the wrong dashboard.
Every dashboard should have a north star metric. The number that matters above all others.
Not five numbers. Not a balanced scorecard. One number.
What to ask:
If they could only see one number, what would it be?
What number, if it moved significantly, would trigger immediate action?
What metric best indicates success or failure?
Examples:
E-commerce: Revenue per visitor (not total revenue, not traffic) SaaS: Net revenue retention (not MRR, not customer count) Support team: First response time (not total tickets, not CSAT) Content team: Engaged minutes per post (not views, not shares)
Once you know the one number, everything else on the dashboard should either explain it, add context to it, or help diagnose problems with it.
A good dashboard structure:
Big number at top (the one that matters)
Trend over time (is it getting better or worse?)
Breakdown by key dimensions (where is it good/bad?)
Diagnostic metrics (why is it moving?)
If you can’t identify one primary metric, the dashboard will become cluttered because everything feels equally important.
This determines everything about how you build it.
Daily dashboard needs:
Fast load time (nobody waits 30 seconds)
Mobile-friendly (people check on phones)
Instant insight (no digging required)
Yesterday’s data minimum (preferably real-time)
Weekly dashboard can have:
More complexity
Desktop-optimized is fine
Deeper analysis
Slightly older data acceptable
Monthly dashboard should have:
Executive summary view
Trends and patterns, not daily noise
Commentary explaining what happened
Comparisons to previous periods
What to ask:
How frequently will the primary user open this?
What time of day/week?
How much time will they spend on it?
Is this for monitoring or deep analysis?
Red flag: If they say “it would be nice to have this available anytime someone wants it” - that usually means nobody has a specific use case. Build for specific use cases, not general availability.
If looking at the dashboard doesn’t lead to action, it’s not useful.
Bad answer: “They’ll be more informed about our metrics.”
Good answer: “If conversion rate drops below 3%, they’ll investigate which traffic source changed and adjust ad spend accordingly.”
That’s specific. Condition → Action.
What to ask:
What should someone do if metric X is good?
What should someone do if metric X is bad?
What’s the threshold between “everything’s fine” and “we have a problem”?
Who do they escalate to if they see an issue?
Example action frameworks:
Customer churn dashboard:
Churn rate > 5%: Review recent churned customers, identify patterns, update retention playbook
High-value customer shows declining usage: Assign CSM for immediate outreach
Churn reason “price” increasing: Flag for pricing team review
Website performance dashboard:
Conversion rate drops >10% week-over-week: Check for site errors, payment issues, traffic source changes
Specific product page has high bounce rate: Review page content, load time, images
Mobile conversion significantly lower than desktop: Audit mobile experience
If you can’t define clear “if this, then that” rules, the dashboard will just be something people glance at and move on.
This is the question nobody asks and it kills dashboards.
You build a beautiful sales dashboard with perfect metrics. Sales team doesn’t use it. Why? Because they don’t trust the data. They have their own spreadsheet they’ve used for years.
What to ask:
What data sources do they currently use?
Do they trust the database or do they export and check in Excel?
Are there known data quality issues they work around?
Have previous dashboards failed due to data accuracy?
Common trust issues:
Timing mismatches: Dashboard shows yesterday’s data, they need today’s. Or dashboard updates at 9am but they check at 8am and see stale data.
Definition conflicts: Dashboard says “revenue” but includes refunds. They think of revenue as gross. Numbers don’t match their mental model.
Missing context: Dashboard shows a spike, they know it’s a one-time bulk order, but dashboard doesn’t explain that. They lose confidence in the whole thing.
Can’t verify: They can’t drill down to transaction level to verify the numbers. If they can’t check your work, they won’t trust it.
Solutions:
Include data freshness timestamp (”Updated 2 hours ago”)
Define metrics clearly with tooltips or documentation
Allow drill-down to source data
Include data quality indicators (”3 orders missing region data”)
Match their existing numbers before adding new metrics
If they don’t trust the data, it doesn’t matter how pretty the dashboard is.
People don’t stop doing their job while waiting for your dashboard. They have a current process. Understanding it is critical.
What to ask:
How do they get this information now?
What tools/reports/spreadsheets do they currently use?
What works about their current process?
What’s painful about it?
Why can’t they just keep doing it the current way?
Example scenarios:
Current process: Export CSV from three systems, manually merge in Excel, create pivot tables, email summary to team.
Pain points: Takes 2 hours every Monday, error-prone, can’t see real-time data, hard to share.
Dashboard solution: Automated data integration, pre-built views, accessible to whole team, updates daily.
Current process: Check five different dashboards across different tools.
Pain points: Context switching, inconsistent metrics, can’t see full picture.
Dashboard solution: Single integrated view, consistent metrics, everything in one place.
If your dashboard doesn’t solve an actual pain point from their current process, they’ll just keep doing what they’re doing.
List out the specific questions. Not data points. Questions.
Bad list:
Revenue
Customer count
Conversion rate
Traffic sources
Good list:
Are we on track to hit this month’s revenue target?
Which customer segment is growing fastest?
Which marketing channels have the best ROI?
Where are we losing customers in the funnel?
See the difference? The second list gives you direction. You know what charts to build.
Exercise: Write out 5-10 questions the dashboard should answer. Then map each question to specific visualizations.
Question: “Are we on track to hit this month’s revenue target?” → Visualization: Month-to-date revenue vs target (progress bar or line chart)
Question: “Which products are selling better than last month?” → Visualization: Product comparison table with % change column
Question: “When do most customers churn?” → Visualization: Churn by customer age cohort
If you can’t map questions to specific charts, you don’t have clarity yet.
This is as important as knowing what should be included.
Everything you add makes the dashboard harder to scan, slower to load, and more confusing.
What to ask:
What metrics are interesting but not actionable?
What data is someone else’s responsibility?
What updates too infrequently to monitor?
What’s too detailed for this audience?
Common things that don’t belong:
Vanity metrics: Total all-time users (who cares, what action does this drive?)
Static data: Company info that never changes
Someone else’s KPIs: Sales metrics on a marketing dashboard where marketing can’t influence sales
Too granular: Individual transaction details on an executive dashboard
Redundant metrics: Five different ways to show the same thing
Exploratory analysis: Ad-hoc investigations belong in notebooks, not dashboards
A dashboard with 50 charts is worse than useless. It’s overwhelming. People will look at it once, feel confused, and never come back.
The rule: If removing something wouldn’t impact the user’s ability to make their decision, remove it.
Define success metrics for the dashboard itself.
What to ask:
How many times per week should this be opened?
What user actions indicate they’re getting value?
What would cause them to stop using it?
How will you measure adoption?
Success metrics for dashboards:
Usage frequency: Primary user opens it 3x per week minimum
Action rate: 80% of sessions lead to documented actions or decisions
Time to insight: User finds what they need in under 60 seconds
Replacement rate: Users stop using old reports/spreadsheets within 2 weeks
Retention: 90% of users still active after 3 months
Expansion: Other teams request similar dashboards
Failure signals:
Usage drops to zero after first month
Users keep requesting custom reports outside the dashboard
Lots of “can you add this metric?” requests (scope creep)
Users export data and analyze elsewhere
You have to keep reminding people to use it
Set a review date: Schedule a check-in 1 month after launch. If usage is low, find out why. Don’t let zombie dashboards accumulate.
Someone requests a dashboard. You immediately start building. Big mistake.
The request is often vague: “Can we get a dashboard for customer data?”
Your job is to ask the questions above before writing any code or opening Tableau.
Spend an hour asking questions. Save yourself two weeks of rebuilding.
Fancy animations, custom color schemes, elaborate layouts. None of that matters if the core information isn’t there.
Users want: Fast, accurate, actionable information.
They don’t want: Your design portfolio piece.
Priority order:
Correct data
Answers their questions
Fast load time
Easy to understand
Looks professional (dead last)
“I’ll add lots of filters so they can slice the data any way they want!”
This backfires. Too many options = decision paralysis.
Better approach: Build for the 80% use case. Default view answers the core questions. Advanced filters available but not required.
You build it, send the link, assume people will figure it out.
They won’t.
Every dashboard needs:
What this dashboard shows (1 sentence)
Who should use it and how often
How to interpret the key metrics
What actions to take based on what they see
Data freshness and known limitations
Who to contact with questions
This can be a tooltip, a help tab, or a linked doc. But it needs to exist.
You launch the dashboard. Usage starts strong. Then drops off. You never check.
Better approach:
Monitor usage weekly for first month
Schedule feedback session after 2 weeks
Review usage quarterly
Retire dashboards that aren’t being used
Update dashboards when business processes change
Dashboards aren’t “done” when you launch them. They require maintenance.
Sometimes the answer is: Don’t build this.
Don’t build a dashboard if:
The need is one-time: Someone needs analysis of Q3 results. That’s a report, not a dashboard.
The data doesn’t exist yet: They want metrics from a new product that hasn’t launched. Wait until you have data.
Nobody can articulate the decision: If they can’t tell you what they’ll do differently based on this data, it’s premature.
The data quality is terrible: Fix the data pipeline first. A dashboard on bad data is worse than no dashboard.
It’s just for you: Analysts sometimes build dashboards for themselves. That’s fine, but don’t treat it as a project. Keep it simple.
There are bigger priorities: Dashboard requests are endless. Prioritize ruthlessly. A dashboard that saves 5 hours a week beats one that saves 30 minutes.
Alternative solutions:
Instead of a dashboard, consider:
Scheduled email report: For infrequent monitoring
Slack alert: For threshold-based notifications
Ad-hoc analysis: For one-time questions
Data export + documentation: For power users who want to do their own analysis
Improved existing dashboard: Before building new, could you enhance what exists?
Let’s put this all together with a real scenario.
Request: “We need a customer support dashboard.”
After asking the questions:
Primary User: Jessica, Support Team Lead Decision: Which support agents need coaching, which tickets need escalation Frequency: Checks every morning, reviews deeply on Fridays
Core Questions:
Do we have tickets approaching SLA breach?
Which agents have high backlog or long resolution times?
Are we seeing patterns in ticket types or customer complaints?
Is customer satisfaction trending up or down?
Primary Metric: Tickets at risk of SLA breach (next 24 hours)
Action Triggers:
Any ticket within 2 hours of breach → Escalate immediately
Agent has >15 open tickets → Redistribute workload
CSAT drops below 4.0 for any agent → Schedule coaching
New ticket type appears frequently → Document and train
Current Process: Checks 3 different tools, exports to Excel, manually flags at-risk tickets. Takes 30 minutes every morning.
Data Trust: Existing ticket system has accurate data but poor reporting. Jessica trusts the source, just needs better views.
What’s NOT included: Financial metrics, customer lifetime value, marketing source of tickets (not her responsibility, can’t act on it)
Dashboard Design:
Top Section (The Alert Zone):
Big red number: Tickets at SLA risk in next 24 hours
List of those specific tickets with time remaining
One-click escalation button
Middle Section (Team Performance):
Table of agents: open tickets, avg resolution time, CSAT
Color coding: Green (good), Yellow (attention), Red (intervention needed)
Trend arrows showing improvement/decline
Bottom Section (Patterns & Insights):
Ticket volume by category (this week vs last week)
CSAT trend (last 30 days)
Top 5 recurring issues
Success Criteria:
Jessica opens it every weekday morning
Reduces SLA breaches by 50% in first month
Cuts morning prep time from 30 min to 5 min
Team leads start asking for access
That’s a dashboard that will actually get used. Because it was designed around specific needs, not generic ideas about what support dashboards should include.
Don’t start building until you can answer yes to all of these:
I can name the specific people who will use this
I can describe the exact decision this supports
I know the one metric that matters most
I know how often they’ll check this (daily/weekly/monthly)
I’ve listed specific questions it should answer
I know what action they’ll take based on what they see
I understand their current process and pain points
I know what data they trust and why
I’ve defined what success looks like
I’ve agreed on what’s NOT included
I have a scheduled review date after launch
If you can’t check all these boxes, you’re not ready to build. Go ask more questions.
Most dashboard failures happen before a single chart is created. They happen when someone says “yes” to a vague request without understanding the real need.
Your job isn’t to build dashboards. Your job is to help people make better decisions faster.
Sometimes that means building a dashboard. Sometimes it means sending them a weekly email. Sometimes it means teaching them SQL so they can answer their own questions.
The dashboards that succeed are the ones built for specific people solving specific problems. Everything else is just decoration.
Next time someone asks for a dashboard, don’t open Tableau. Open a conversation. Ask these questions. Push back on vague requirements. Insist on clarity.
You’ll build fewer dashboards. But the ones you build will actually matter.
And that’s the point.
Best of luck for everything!
- Sai Bysani, a fellow Hustler!
Keep grinding, keep growing,
The Data Hustle.
No posts
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.