Why I Build Systems, Not Dashboards

A humanitarian coordinator walks into my office. "Can you make me a dashboard?" she asks.

This is a phrase I've heard a hundred times. And every time, I know that the question is not actually about dashboards.

What she's really asking is: "Can you help me see what's happening in my program?" or "Can you help me make better decisions?" or "Can you give me something to show my donors?" The dashboard is just the medium she's imagining.

But dashboards are rarely the answer. And if you build the wrong thing at the beginning, you end up in a familiar place: a beautiful visualization that nobody uses, updated once and then abandoned, a monument to someone's good intentions.

Dashboards become graveyards. I've seen it dozens of times across humanitarian organizations. Someone commissions a beautiful dashboard—maps, charts, metrics, all color-coded and interactive. It launches to fanfare. Then it's updated three times and nobody looks at it again.

Why? Because dashboards solve the wrong problem.

A dashboard answers the question: "What do the numbers say?" But that's rarely the question that matters. The question that matters is: "What should I do about it?"

Organizations confuse data visibility with data utility. They think "If we can see the data, we'll make better decisions." But seeing the data doesn't automatically change behavior. You can show someone a chart that says "dropout rates are 23% higher in region X" and they still have no idea how to act on that information.

Worse, dashboards create a false sense of understanding. You're looking at a graph and thinking "I understand the situation." But you're looking at aggregated numbers that might be wrong, outdated, or misleading. A dashboard is a view. It's useful for getting a general sense of direction. It's terrible for understanding the actual situation.

The fundamental problem: dashboards show you numbers. They don't change your workflow.

ReportHub was a system. Let me trace what that actually means.

The problem it solved: humanitarian organizations collect data in silos. Each organization reports to its donors in its own format using its own definitions. A cash program reports differently than a food program, which reports differently than a health program. To see a coordinated picture, you have to manually compile data from dozens of sources. This takes weeks. By the time you've compiled it, the situation has changed.

The system we built had multiple layers: - Data standards (what gets reported, in what format, with what definitions) - Collection tools (mobile forms, web intake, API integrations for existing systems) - Validation pipelines (automated checks to catch bad data early) - Coordination mechanisms (ways for organizations to share data, see shared dashboards, coordinate action) - Feedback loops (a way for field teams to challenge data and corrections to flow back)

Not one of these pieces was a dashboard. Most of them weren't even visible to end users. They were infrastructure.

But here's what changed: organizations stopped sending me spreadsheets. The reporting burden dropped by 60%. Analysts spent less time compiling and more time analyzing. Coordination happened faster because people could see shared data. Donors got better information because the data was more timely and reliable.

200+ organizations used ReportHub. Not because the dashboards were beautiful. Because the system reduced their burden and gave them something useful to work with.

That's what a system does. It doesn't just show you data. It changes your workflow. It makes certain actions easier and other actions harder. It creates incentives. It builds in quality control. It amplifies good behavior and makes bad behavior visible.

Every information system should answer three questions. If it doesn't answer all three, it's just decoration.

Question 1: Who needs this data? Not "who might want this data," but who specifically, for what role, in what context. A field coordinator needs different information than a country director needs different information than a program manager. If you don't know who the user is, you can't build for them.

Question 2: What decision does it inform? Data without an associated decision is just noise. If the data doesn't help someone decide something specific, it doesn't belong in the system. A humanitarian coordinator needs to decide: do we scale the program to region X? Do we change the targeting criteria? Do we shift resources? What specific decision does your data support?

Question 3: How does it get to them at the right time? Timeliness is underrated. A perfect analysis that arrives after the decision has been made is worthless. A rough analysis that arrives when it can still change an outcome is gold. Systems that work think about information flow. How often does this person need this data? Do they need it pushed to them proactively? Do they need it available when they ask? Does it need to trigger an alert?

Most information projects fail because they answer the wrong question. They show you everything without thinking about who's using it, why they're using it, and when they need it.

Build the system around the decision, not around the data.

The next time someone asks you for a dashboard, ask them what decision they need to make. That's where you start.

If they say "I want to see program performance," dig deeper. Which metrics? For what decision? If they say "I want to monitor beneficiary outcomes," ask which outcomes, measured how, and what you're going to do differently based on what you see.

Dashboards are fine tools for certain purposes—general awareness, donor reporting, directional understanding. But if you want to actually change how an organization operates, if you want to build something that gets used, you need to build a system.

Start with the decision. Build backwards from there. Then you might end up with something worth building.