The Dashboard Trap
Dashboards are everywhere. Every B2B product has one. Most of them are bad.
The typical dashboard: a wall of charts, numbers flying at you, widgets competing for attention. It says "look how much data we have!" without answering "what should you do about it?"
Building dashboards for Zorp CMMS -a maintenance management system for facilities teams -taught me what dashboards should actually be: decision-making tools, not data decoration.
What Dashboards Are For
Dashboards have one purpose: helping users make better decisions faster.
Everything else -impressive visualizations, comprehensive data, fancy animations -is secondary. If a dashboard doesn't improve decisions, it's failed.
Questions your dashboard should answer:
- What needs my attention right now?
- Is anything abnormal that I should investigate?
- How am I trending toward my goals?
- What actions should I take?
Questions most dashboards actually answer:
- How much data do we have?
- Can we make this look like the competitor's dashboard?
- What charts can we fit on one screen?
Start with decisions, not data.
Information Hierarchy
The Inverted Pyramid
Newspapers put the most important information first. Dashboards should too.
Top tier (immediate attention):
- Alerts and warnings
- Items requiring action
- Critical status changes
Middle tier (context):
- Key metrics and trends
- Progress toward goals
- Comparative benchmarks
Bottom tier (detail):
- Granular data for investigation
- Historical context
- Supporting information
Users should be able to scan the top tier in seconds and know if they need to dig deeper.
Visual Hierarchy Techniques
Size: Important things are bigger Position: Important things are top-left (in LTR languages) Color: Alerts use color strategically -don't oversaturate Animation: Motion draws attention -use sparingly Whitespace: Breathing room around important items makes them stand out
The goal: eyes are drawn to what matters most.
The "Glance Test"
Can users understand dashboard status in 3 seconds?
If dashboards require study to interpret, they've failed. Aim for immediate comprehension of overall status, with detail available on demand.
Lessons from Zorp CMMS
Lesson 1: Start with the Problem, Not the Data
Our initial CMMS dashboard showed everything: work orders, asset status, maintenance schedules, inventory levels, team assignments, performance metrics.
Users were overwhelmed. In user research, a facilities manager said: "I just need to know what's broken and what's coming due. Everything else is noise."
We rebuilt around those two questions:
- What needs fixing now?
- What's about to need fixing?
The dashboard became dramatically simpler and dramatically more useful.
Lesson 2: Actionable > Informational
Data without action is decoration.
Before: "There are 47 work orders open." After: "12 work orders are overdue. [Review them]"
Every metric should suggest or enable action. If there's nothing to do about a number, question whether it belongs on the dashboard.
Lesson 3: Preemptive Beats Reactive
The best dashboards prevent problems:
Reactive: "Pump 3 has failed." Preemptive: "Pump 3 will need maintenance in 14 days based on runtime."
Predictive insights -even imperfect ones -help users stay ahead rather than constantly firefighting.
Lesson 4: Context Makes Numbers Meaningful
"47 work orders" means nothing without context.
Better: "47 work orders (vs. 32 avg)" Even better: "47 work orders - 47% above normal. [See surge details]"
Comparisons (to averages, goals, previous periods) transform numbers into insights.
Lesson 5: Mobile Is Different, Not Smaller
Our users lived on their phones, walking through facilities. Desktop dashboard crammed onto mobile didn't work.
Mobile dashboard principles:
- One focus per screen
- Thumb-friendly interactions
- Fewer options, clearer paths
- Offline capability for poor connectivity
We built a mobile experience that was reimagined, not responsive.
Data Visualization Choices
When to Use What
Numbers: For precise values users need to act on. "7 overdue work orders"
Progress bars: For completion toward goals. "Budget: 73% used"
Sparklines: For quick trend indication. "Uptime trending down over 7 days"
Bar charts: For comparing categories. "Work orders by building"
Line charts: For time-series trends. "Maintenance costs over months"
Pie charts: Almost never. Hard to read, hard to compare. Use bar charts instead.
Chart Design Principles
Remove chartjunk: No 3D effects, no unnecessary gridlines, no decorative elements
Label clearly: What does this axis mean? What time period is this?
Use color meaningfully: Red doesn't always mean bad (unless consistently so)
Design for reproduction: Will this be understandable in a screenshot? In a report?
The Zero Baseline Rule
Bar charts and line charts should start at zero unless you have compelling reason otherwise. Non-zero baselines exaggerate differences and mislead.
Alert and Notification Design
Alert Hierarchy
Not all alerts are equal. Create clear tiers:
Critical: System is down, safety risk, requires immediate action Warning: Something is wrong but not urgent Info: Notable event, no action required Success: Confirmation that something worked
Use color, iconography, and placement consistently across tiers.
Alert Fatigue
Too many alerts = no alerts. Users tune out constant notifications.
Solutions:
- Aggregate related alerts
- Let users customize alert thresholds
- Escalate only when patterns emerge
- Provide "dismiss" and "snooze" options
An alert that's never actionable shouldn't be an alert.
Alert Actionability
Every alert should have clear next steps:
"Pump pressure exceeding threshold. [View pump] [Acknowledge] [Create work order]"
Don't just notify -enable response.
Dashboard Anti-Patterns
The Everything Dashboard
Cramming every possible metric onto one screen. Users see everything, process nothing.
Fix: Ruthlessly prioritize. Default views show essentials; detail is optional.
The Vanity Dashboard
Impressive-looking charts that don't help decisions. Executive showcase rather than working tool.
Fix: Ask for every element: "What decision does this inform?"
The Stale Dashboard
Data that updates slowly, hourly instead of real-time, showing yesterday's situation.
Fix: Display data freshness. Real-time where it matters. Stale data acknowledged.
The Static Dashboard
One size fits all. No customization. Users can't focus on their responsibilities.
Fix: Personalization. Role-based defaults. Saved views.
The Mystery Dashboard
Unclear what numbers mean, where data comes from, how to interpret variations.
Fix: Labels, tooltips, data source indicators, contextual help.
Building Effective Dashboards
Discovery Phase
Before designing:
- Who uses this dashboard?
- What decisions do they make?
- What questions do they ask?
- What data do they need?
- How often do they check in?
User research shapes every subsequent decision.
Information Architecture
Map the hierarchy:
- What's most critical?
- What provides context?
- What's needed occasionally?
- What can be removed?
Most dashboards have too much at tiers 1-2 and not enough discipline about tier 4.
Design Phase
Build for actual usage patterns:
- Morning check-ins (status overview)
- Issue investigation (drill-down capability)
- Reporting preparation (export and summarization)
- Mobile glances (essential status only)
Different usage patterns need different views.
Testing and Iteration
Test with real users on real tasks:
- "Show me how you'd find overdue work orders"
- "What would you do first when looking at this dashboard?"
- "What's confusing or missing?"
Dashboards benefit enormously from iteration based on actual use.
The Well-Designed Dashboard
A well-designed dashboard:
- Answers the most important questions immediately
- Guides attention through visual hierarchy
- Enables action, not just observation
- Adapts to different users and contexts
- Shows what's changed, not just what is
- Fails gracefully when data is unavailable
- Respects users' time and attention
These principles seem obvious. Most dashboards violate them.
Build dashboards that help people decide and act. That's the whole job.
What dashboard design challenges have you tackled? What worked and what didn't?