Building Dashboards Your Team Will Actually Use

The Dashboard Graveyard

Every organization has one: a collection of dashboards that someone spent weeks building, that got used for a month, and that now sit untouched while everyone goes back to their spreadsheets.

Why does this happen? Usually because the dashboard was built for data, not decisions.

Data vs. Decisions

A data-focused dashboard asks: "What information do we have?" A decision-focused dashboard asks: "What do we need to know to act?"

These sound similar but lead to completely different designs.

A data-focused dashboard might show you total AUM, broken down by asset class, manager, geography, and vintage year—all on one screen. Comprehensive? Yes. Useful? Only if you're doing a deep dive analysis.

A decision-focused dashboard asks: "What decisions does this team make, and what do they need to see to make them well?"

Start with the Meeting

The best way to design a useful dashboard is to sit in on the meetings where decisions get made. Watch what people actually look at. Listen to the questions they ask. Note when someone says "let me pull up the spreadsheet" or "I'll have to get back to you on that."

Those moments are your design brief.

Common decision points for investment committees:

• Rebalancing: Are we within our target ranges? What's drifted?
• Manager review: How is each manager performing? Any red flags?
• Liquidity: What's our cash position? What's coming due?
• Risk: Are we taking the risks we intend to take?

Each of these is a potential dashboard view—focused on a specific decision with only the information needed to make it.

The One-Screen Rule

Here's a useful constraint: each dashboard view should answer one question on one screen without scrolling.

This forces you to prioritize. You can't show everything, so you have to show what matters. If someone needs to drill down for more detail, that's a separate view.

This constraint also makes dashboards usable on laptops during meetings, on tablets during travel, and on phones when someone calls with a question.

Design Principles That Work

Show the answer, not the data

Don't make users calculate. If the question is "are we overweight equities?", show the current allocation vs. target with the variance highlighted. Don't show raw numbers and expect people to do math.

Use color sparingly and consistently

Red means something needs attention. Green means fine. Yellow means watch it. That's it. Don't use color for decoration or to make things look prettier.

Default to the most common view

If 90% of the time someone wants to see current quarter performance, that's what should appear when they open the dashboard. Don't make them click through to get to the thing they always want.

Make drill-down obvious

When someone can click for more detail, make it clear. Underlines, arrows, or hover effects. Don't hide functionality.

The Spreadsheet Test

Here's how you know if your dashboard is working: are people still exporting to Excel?

If yes, find out why. Common reasons:

• They need to manipulate the data: Your dashboard might need more flexibility
• They need to share with someone who doesn't have access: Consider a PDF export or simpler sharing
• They don't trust the dashboard numbers: That's a data quality problem, not a design problem
• Habit: They might just need encouragement to try the new way

The goal isn't to eliminate spreadsheets entirely—they're useful tools. The goal is to eliminate unnecessary spreadsheet work.

Getting Adoption

Even a well-designed dashboard won't get used if you just throw it at people. Roll it out intentionally:

1. Start with champions: Find 2-3 people who are frustrated with the current process. Get their input on design and let them be early users.

1. Use it in meetings: Project it during investment committee meetings. Let people see it in action.

1. Iterate quickly: When someone asks for something the dashboard doesn't do, add it if it makes sense. Early responsiveness builds trust.

1. Kill the old way: At some point, stop distributing the old reports. If the dashboard works, make it the default.

Maintenance Matters

Dashboards die when they stop being accurate. One wrong number destroys trust.

Build in a maintenance plan from the start: - Who's responsible for data quality? - What happens when a data source changes? - How do you handle exceptions and errors?

The dashboard is only as good as the data behind it, and data requires ongoing attention.

Bottom Line

The best dashboard is the one that gets used. Start with decisions, not data. Design for the meeting, not the demo. And be prepared to iterate based on how people actually use it.