Dashboard UX starts with speed, then storytelling

There is one sentence I keep coming back to when I judge a dashboard. It sums up the second year of building a BI area for a consulting firm that serves private schools in Brazil, when we moved our data out of Excel files and into SQL Server. The reason for that move, in the end, was the person on the other side of the screen:

It all comes down to giving the user a good experience. Delivering a wonderful dashboard that takes minutes to render doesn't work. You need the right information, available, with no delays and no bugs.

Most advice about dashboard design starts with colors and charts. I start with that sentence, because a dashboard nobody waits for is a dashboard nobody uses. Design comes second, and it matters a lot once the first part is solved.

Speed is the first UX requirement

People think of user experience as layout. In BI, the first thing the user experiences is the wait.

Our data used to live in Excel. Spreadsheets have obvious limits on size and on who can reach the information, and crossing one dataset with another was painful for anyone who tried. Moving the bases to SQL Server made the data easier to maintain and work with, and it made the information safer. I told that part of the story in from Excel to SQL Server.

The payoff for the reader came the year after, when we rebuilt every report in Power BI on top of the new database. The user experience improved, and so did the performance of the semantic models. Analyses got faster and more accurate. No visual redesign could have produced that improvement, because the problem was underneath the visuals.

A few habits follow from this:

• Measure how long a report takes to open before you discuss how it looks.
• Fix slowness at the source. The data model and the database usually matter more than the chart.
• In a data warehouse, denormalized tables trade some redundancy for faster reads. For reporting, that trade is often worth it.
• Treat a wrong number as the worst kind of bug. Speed means nothing if the reader stops trusting what they see.

Tell a story, not a chart dump

Once the dashboard is fast and correct, the next question is whether anyone understands it.

Storytelling with data means building a narrative around the numbers, so the reader gets context and not only values. A monthly sales chart on its own shows peaks and dips. The same chart with the marketing actions that happened along the way explains them, and the reader walks away knowing what to repeat.

A simple way to apply this is to ask three things of every page:

1. What is the one question this page answers?
2. What should the reader notice first?
3. What can they do differently after reading it?

If a page can't answer the first question, it is probably two pages pretending to be one.

Design that doesn't make people think

A good dashboard feels obvious. That feeling comes from consistency more than from talent.

Use colors, shapes and layout the same way everywhere. Group related information together. Give each category a distinct color, but keep the palette short, because every extra color is one more thing the reader has to decode. Put the main KPIs at the top, where the eye lands first, and let the details follow below.

Consistency also pays off across reports. When every dashboard in a portfolio follows the same rules, a reader who learned one can read the next without help.

Let people ask the next question

A static report answers the questions its author thought of. An interactive one lets the reader ask their own.

Filters, sliders and drill-downs turn a dashboard into something people can explore. Click a region on a chart and see its details. Change the date range and compare periods. One of the most useful patterns I know is a map that filters every other element on the screen when you click an area: the reader picks a place and the whole page follows.

Interactivity has a cost, though. Each filter is another thing to understand, and each drill-down path has to make sense. Add interactions that answer real follow-up questions, not every option the tool allows.

Test with the people who will use it

The last step is the one teams skip most often. Before you launch a dashboard, put it in front of the people who will use it and watch them try.

Usability tests catch problems the author can no longer see: a filter nobody finds, a label that means something else to the business, a page that answers a question nobody asks. After launch, keep collecting feedback. The interface should keep improving as the reader's needs change.

A checklist I would use again

To review a dashboard, go through this short list, in this order:

1. Does it open fast, and are the numbers right?
2. Is there one clear question per page?
3. Are the main KPIs at the top?
4. Is the palette short and consistent with the other reports?
5. Do the filters and drill-downs answer real follow-up questions?
6. Has someone who will use it tried it before launch?

Speed and correctness come first because they decide whether anyone reaches the rest of the list. Everything else turns a working dashboard into one people enjoy using.

If one of your dashboards fails the first item on that list, tell us about it.