How to Build a Dashboard People Actually Use

Most dashboards fail. They get built in a burst of enthusiasm, opened twice, and then quietly ignored. The problem is almost never the charting library - it's that the dashboard was built around whatever data happened to be available, instead of the questions people actually ask.

Here's how I build dashboards that people keep open in a tab.

Start with questions, not charts#

Write down the five questions you want answered every morning, in plain English. "Are signups growing?" "Where do new users drop off?" "Did that deploy break checkout?" Each question becomes exactly one chart. If a chart doesn't answer a question on the list, cut it - you can always add it back when someone asks for it.

This sounds obvious, but it inverts how most dashboards get made: people browse the available data and chart whatever looks chartable. That's how you end up with thirty graphs and no answers.

Pick a handful of metrics#

A dashboard should fit on one screen without scrolling: five to seven metrics, no more. If you have more questions than that, make more dashboards - one per audience. The founder dashboard (revenue, signups, churn risk) is not the product dashboard (activation, feature usage, funnel drop-off) is not the growth dashboard (channels, conversion). Retention curves belong on the product one, not all three.

Match the chart to the question#

• Line chart - how is something trending over time?
• Big number - what is the value right now (MRR, signups today)?
• Bar chart - how do categories compare (plans, channels, countries)?
• Funnel - where do people drop off between steps?
• Table - only when someone needs to look up individual rows.

If you reach for a pie chart, stop - bars are easier to read past three slices. And every chart needs a time range and a comparison ("vs previous period") to mean anything; a naked number invites the wrong conclusion.

The hard part is the data, not the charts#

Charting is a commodity - every library draws a fine line chart. The actual work is getting clean events stored and queryable: deciding what to log, getting it into a database, and writing the queries. That's the part that makes "let's build a dashboard" turn into a six-week project.

The shortcut is to log events as JSON from your app - a single POST per event - and query them with SQL when you need a new chart. Our SQL cheat sheet covers the queries behind most standard dashboard panels.

The lazy way#

GraphJSON generates an analyzed dashboard from your events automatically - top keys, value distributions, event volume - the moment you start logging. From there you can filter, customize, and add SQL-backed charts in a notebook. And if the audience is your customers rather than your team, the same dashboards can be embedded in your product or turned into personalized per-user dashboards.