Our Love Affair With the Dashboard (Breaking Up Is Hard to Do)

You’re reviewing the product roadmap in a meeting and you hear, “We need a dashboard.”

Everybody loves a dashboard, right? Dashboards let you know at a glance what the status of everything is. A dashboard is a jumping-off point from which, prepared with perfect information, you can proceed to do all the most important things. Who wouldn’t want that?

Falling In Love with the Dashboard

As UX designers, it’s fun to design dashboards.  We can spend days arranging boxes with labels in and around the boxes. Dashboards often have charts, so we can do cool stuff like draw curves and create colorful, semi-translucent overlays.

Stakeholders love dashboards because dashboards seem like an expedient way to communicate everything important about the product in one screen.  They expect it to anchor the entire product, to give it heft and depth. Their hope is that, upon arriving at the dashboard, the users are immediately up to speed and informed about all the important things, and that they’re ready to launch into whatever activity is prescribed by that healthy data dose.

But Dashboards Are Not Always the Answer

Dashboards fall short of our expectations all the time. Some reasons why:

One time use. You launch a dashboard and everybody loves it. On Day One it tells a compelling story and offers great insights. But six months later it’s still telling the same story and offering the same insights. You realize that the experience of most of your customers is not changing. Their settings haven’t changed. Their metrics have remained stable. They stopped clicking through on the alerts long ago. To them, your dashboard is a static page, and the value is gone.

Data is more complicated than you thought. It’s not hard to estimate how long it will take to build a graph that displays data that’s in a standard form. But as soon as you plug into a production database, you realize that the data is more complicated (and perhaps dirtier) than you thought. For example, one field in a database may have represented different things at different points in its lifetime. And in order to make the dashboard look right, you need to write lots of conditional logic and clean up the data--which can take months.

Insights don't materialize. When you conceive of the dashboard, you ask yourself, ‘What data trend would look good here’, and you mock up data that supports that trend. Even when it’s clean, the real data often doesn’t cooperate. Real data often doesn’t show a trend. Canned insights fail to materialize. Sometimes data shows competing trends. It invites false conclusions.

Data exploration is inhibited. The dashboard often shows data that, at some point in your product’s infancy, was offered as a data export or a report or even a raw query that you had to run for your customer on occasion. Those ‘question-asking’ modes of gathering data are valuable. When we build a dashboard, we are in a sense trying to anticipate the questions and present data that can be perceived more as direction than as an answer to a question. Reporting interfaces and raw data exports actually encourage exploration of raw data with tools that are table stakes for business users. Building a dashboard may inhibit that data exploration.

Wrong persona. You build the dashboard for an executive. The executive uses it on Day One, but then hands off all of the operational aspects to somebody who does not find the dashboard useful.

What Happens When You Look Beyond the Ask

It’s not enough to just say no to a request to build a dashboard. There is always a reason for the request. Just try to dig a little deeper to understand what’s needed.

You may discover: you don’t know what users want to do

Suppose you’re a domain registrar. You want to redesign your post-login home page so that the users know about your new services: website building, hosting, email, domain privacy, SSL certificates, and the like. You are about to give in to a request to create a dashboard that shows the status and recent uptime of all of those services. The dashboard would show all green lights and >99% uptime, assuming that has and will be the case.

But if you actually talk to users, you may find that most users looking at the logged-in home page just want to find out whether a domain is available. A small percentage of visitors are actual users of the new services. The right solution may turn out to be a post-login overlay that informs the users about the new services, and lets them dismiss it.

You may discover: you need a way to prove that your product works

You are at work on a groundbreaking idea that will save new college grads thousands of dollars in managing their student debt. Your investors are keen to see something working that validates your idea. You know that your product will eventually need a dashboard to show how repayment of loans is progressing. It would be easy to show a ‘working product’ with the dashboard alone. So you’re tempted to build the dashboard first, as a demo to investors.

But you understand that if you can save students hundreds of dollars *now*, then they will sign up whether or not you can show them a dashboard. And bringing ten student advocates to your next investor meeting turns out to be a much more compelling demo.

You may discover: users want to see data and act

You run a site that allows users to create charitable campaigns. You’re considering whether to build a dashboard for users to manage their existing campaigns. You understand that the most sensible thing for a person who doesn’t have a campaign to do is to start a campaign, and you have optimized for that. But you also know that most users have one cause and one campaign that they are passionate about. After setting up a campaign most users want to log in and see how the campaign is doing.

Your users tell you that there are four important things for them to track over time:

  • total number of donors
  • % of gifts that are recurring
  • total number of gifts
  • source of referrals

And there are three primary actions they wish to take based on this information:

  • Extend a campaign’s end date
  • Message the donors
  • Create a post about the campaign for embed in social

Since users are telling you exactly what they need to know, and what they want to do, you can display that information compactly and also accommodate their need to take basic actions based on the information they see. Sometimes building a dashboard makes perfect sense!

Can We Help You?

Can we talk you out of building a dashboard? Or maybe we can help you find out what you really should be building. Get in touch.


Photo by Dan Lohmar on Unsplash

Continue the conversation.

Lab Zero is a San Francisco-based product team helping startups and Fortune 100 companies build flexible, modern, and secure solutions.