I've shipped 23 dashboards over the past eight years. Twelve of them failed. By "failed" I mean: within six months, usage dropped to near zero, and stakeholders went back to asking for ad-hoc reports.
Here's what I learned from the failures—and the successes.
Why Dashboards Fail
Before building, understand the failure modes:
1. The "Too Much" Dashboard
Symptoms: 15+ charts, multiple scroll depths, everything is important.
Why it happens: Stakeholders each want "their" metric included. No one says no.
Why it fails: Decision fatigue. Users open it, feel overwhelmed, close it.
2. The "Wrong Question" Dashboard
Symptoms: Beautiful charts, impressive filters, technically excellent.
Why it happens: Building started before understanding what decisions users need to make.
Why it fails: It answers questions nobody is asking.
3. The "Out of Date" Dashboard
Symptoms: Data is hours, days, or weeks old. Users don't trust it.
Why it happens: Technical constraints or poor data pipeline design.
Why it fails: Users check the dashboard, then check the source anyway. Soon they skip the dashboard.
4. The "One User" Dashboard
Symptoms: Perfectly designed for the executive who requested it.
Why it happens: Only talked to one stakeholder.
Why it fails: That person gets what they need. Everyone else's needs go unmet.
The Research Phase (Don't Skip This)
Before any design work, I now spend 2-3 weeks on research. This single change transformed my success rate.
Talk to 5-8 Potential Users
Not their managers. Not the executive sponsor. The people who will actually look at this daily.
Ask:
- What decisions do you make repeatedly?
- What information do you need for those decisions?
- Where do you currently get that information?
- What's annoying about the current process?
Shadow Users
Watch them do their current workflow. You'll see inefficiencies they don't mention because they're used to them.
I once watched a sales manager copy data from three different tools into a spreadsheet every Monday. She didn't mention it because "that's just how it works." The dashboard I built automated that entirely.
Find the "Aha" Moment
What single insight would make someone's day easier? Start there. A dashboard that does one thing brilliantly beats one that does ten things adequately.
Design Principles That Work
1. Start with One Screen
Challenge yourself to fit everything on one screen without scrolling. This forces prioritization.
If you must scroll, the first screen should contain the most critical information.
2. Lead with the Number
Don't make users hunt for the headline. The main KPI should be the first thing they see—big, clear, and with enough context to interpret (vs. target, vs. last period).
3. Progressive Disclosure
Surface-level view shows the summary. Clicking reveals detail. Advanced filters hidden until needed.
Most users never need the detail. Power users can access it without cluttering the default view.
4. Actionable > Interesting
Every chart should suggest an action. If it doesn't lead to a decision, question whether it belongs.
Bad: "Website traffic over time"
Better: "Traffic vs. goal (take action if below yellow line)"
5. Update Frequency Matches Decisions
If decisions are made monthly, daily updates add noise, not value.
If decisions are made hourly, daily data is useless.
Match the refresh rate to how often people check it and act on it.
The MVP Dashboard
Start minimal. Here's the structure I use:
Header
- Dashboard title and last updated time
- Key metric in large format
- Target or comparison
Main Section
- 2-3 charts maximum
- Each answers a specific question
- Clear hierarchy (one chart is primary)
Optional Detail Section
- Collapsible or below the fold
- Supports deep-dives when needed
No Filters Initially
Yes, really. Filters add complexity. Launch without them and see if users actually need them. Often they don't.
Building for Adoption
A great dashboard that no one opens is worthless. Plan for adoption from day one.
1. Find Champions
Identify 2-3 early users who will actually use it and give feedback. Build for them first.
2. Integrate into Workflows
Can the dashboard appear where people already work? A Slack notification with the daily number. An email digest. Embedded in the tool they already use.
Asking people to open a new tab is asking a lot.
3. Start with a Problem
Launch with: "Remember how you had to pull that report manually? Now it's here automatically."
Don't launch with: "Here's a new dashboard with lots of features."
4. Kill the Old Way
If the old spreadsheet still exists, people will use it. Deprecate the old solution when the new one is ready.
5. Measure Dashboard Usage
Track opens, time spent, filter usage. Low usage is feedback. It means something is wrong.
Iteration After Launch
The first version is never right. Plan for iteration.
Week 1: Daily Check-ins
Talk to users every day. What's confusing? What's missing? What's unnecessary?
Week 2-4: Weekly Reviews
Have users built habits? What questions are they asking that the dashboard doesn't answer?
Month 2: Formal Review
Usage analytics. User interviews. Decide what to add, remove, or change.
Ongoing: Monthly Pulse
Brief check-in. Is it still relevant? Has the business changed?
Red Flags and How to Fix Them
"Can you add..."
Too many addition requests = original scope unclear. Go back to core questions.
"The data doesn't look right"
Trust is fragile. Investigate immediately. One unexplained discrepancy can kill adoption.
Low usage but no complaints
People are too polite to complain. Proactively ask: "If you had to rebuild this, what would you change?"
The "owner" stops caring
Every dashboard needs an accountable owner. If they move on, assign someone new or sunset the dashboard.
Tools and Technology
The tool matters less than the process. I've built successful dashboards in:
- Excel (yes, really)
- Google Sheets
- Tableau
- Power BI
- Custom web apps
- AI-powered tools like ChartGen.ai
The best tool is the one your users can access and trust.
What matters:
- Reliable data refresh
- Fast load times
- Accessible on devices users have
- Maintainable by the team
Case Study: The Dashboard That Worked
A B2B SaaS company asked for a "customer health dashboard."
Initial request: 40+ metrics across product usage, support tickets, billing, and NPS.
Research finding: Customer Success Managers actually needed to answer one question each morning: "Which customers need attention today?"
Final design: One page. List of customers sorted by "health score." Three indicators per customer: usage trend, support sentiment, payment status. Click to expand details.
Result: 94% daily active usage after 6 months. CSMs said it cut their morning routine from 45 minutes to 10 minutes.
Final Thought
The goal isn't to build a dashboard. It's to make someone's job easier.
Start there. Work backwards. And don't be afraid to ship something small that people actually use.
A simple dashboard that gets opened daily beats a sophisticated one that gets ignored.