Designing dashboards people will actually use

Dashboarding and data visualization are hot-button topics in the analytics industry, and for good reason. Effective dashboards can democratize access to data across an organization and help foster a culture in which data is used to drive more and more decisions with demonstrable business outcomes.

However, in my experience consulting with enterprises across a variety of industries, I’ve found that too often, dashboards are all hat and no cattle. In other words, the effort, time and money invested in dashboards too often result in disappointment and frustration.

To help you avoid this same frustration, I’ve outlined three common issues with dashboarding projects.

First, it’s very common to find that dashboards don’t have a clear role, or don’t uniquely address a need for stakeholders within an organization.

Second, and on a related note, the organizational conversation about dashboarding tends to immediately jump into a debate about tools — which tool has which features, and so on — before due consideration is given to the data sources “upstream” of the ultimate dashboard.

Ask yourself: Do you trust that data? Are data updates automated, or do they require manual upkeep? In short, is it even worth building a dashboard before addressing data “supply chain” issues?

Finally, organizations sometimes neglect to consider the alternatives to dashboards. Even reliable, easy-to-use dashboards commonly go unused — because stakeholders actually have better alternatives.

Clearly define the role of dashboards

It’s critical to align with stakeholders on the role of dashboards. Doing so allows you to clearly define the scope of your efforts and manage the expectations of your stakeholders long-term.

It’s very common to get involved in dashboarding projects whose scopes quickly reach “boil the ocean” status.

In other words, dashboards are supposed to answer, in detail, every possible question and cover every hypothetical eventuality. Different stakeholders add different requirements, and the result is the dashboard equivalent of urban sprawl — dashboards that are crammed with charts and tables, making it difficult to get to the limited amount of stuff that’s important.

So what should the role of dashboards be? For enterprises with a central analytics team (or agency) serving a wide variety of stakeholders, dashboards probably don’t need to answer every possible stakeholder question.

Instead, dashboards should help stakeholders quickly and easily understand when trends in relevant KPIs are changing, so that they can, in turn, ask more informed questions. Armed with these better, more clearly defined questions, analytics teams can serve their clients much more effectively, with specifically tailored analysis and recommendations.

On the other hand, in an environment where analytics is more self-serve (i.e., there is no central analytics team to serve stakeholders), dashboards likely need to provide a deeper level of detail and interactivity. There’s probably also a commensurate need for user training so that data consumers feel comfortable using and getting value out of more complex dashboards.

Either way, before you get into a vendor selection process, and certainly before you start building dashboards, you should have a candid, realistic conversation about the role of dashboards. Nailing this down up front helps ensure that you’ll ultimately build something that your users actually want and helps you manage expectations along the way.

Don’t jump straight into feature and tool comparisons

Even after you’ve aligned on the goals of dashboards, resist the urge to jump next into vendor selection. Stakeholders may come to the table with their own favorite vendor — based on prior experience, marketing or something else.

But before you start debating the merits of Tableau, Domo, Klipfolio, Google’s new Data Studio or one of the many other visualization tools on the market, consider several other important issues first. For example, how many data sources will you need? What does the quality and reliability of that data look like?

You might be surprised how often dashboards get built on top of data that stakeholders don’t trust, or data that is difficult to work with in some way. It’s easy to see how this leads to user frustration. For example, you build a dashboard intended to provide real-time visibility into KPIs — but the KPIs themselves aren’t updated in real time. Suddenly, your “real-time” dashboard only updates daily, weekly or whenever your data entry intern has extra bandwidth.

Before getting into the nitty-gritty of which dashboarding tool is the right one for the job, build out a “map” of your various data sources. Do an audit to assess whether the data contained in those sources is reliable, trusted and usable.

If you find that certain data sources require attention, either address them before building a dashboard or remove them from the scope of your initial build. Once you’re confident in your data sources, you’ll have a much clearer picture of the ingredients you’ll be working with — and you’ll be more ready to wade into the assessment of competing features and tools.

Consider the alternatives

This one’s easy, but frequently overlooked. What are the alternatives to a dashboard, and are they already in place?

Consider an organization looking to build dashboards around web analytics data. What if many of your stakeholders are already Google Analytics or Adobe Analytics “power users?” Do they need a dashboard? Will they use one if you build it? Perhaps not — and that’s okay.

It may well be that in an environment where users are comfortable accessing data with the tools already in place, dashboards aren’t necessary. Just don’t find that out after you choose a tool and put in the work to build out a series of dashboards.

Sticking with our example, even if your stakeholders aren’t power users of GA or Adobe Analytics, they still may not use dashboards — and for good reason. Are they able to request “deep dive” analysis from an analytics team or external agency? I don’t know about you, but I’d be pretty unlikely to spend time learning how to use a new dashboarding tool when I can commission a detailed analysis instead and have results back on my desk in the near future.

Think about the options your stakeholders already have. If they’re comfortable with the tools already available or have resources at their fingertips that make dashboards redundant, you might think twice about whether dashboards make a lot of sense.

Ultimately, we all love dashboards that help organizations grow a more data-driven culture. But that doesn’t mean that any good-looking dashboard will easily win wide adoption in your organization.

Consider what unique role dashboards can play; think about the data sources you’ll need to connect to; and assess the alternatives that your stakeholders already have. By going through that process before selecting a vendor or building dashboards, you’re much more likely to end up with a data visualization solution that makes all your stakeholders happy.

Some opinions expressed in this article may be those of a guest author and not necessarily Marketing Land. Staff authors are listed here.

About The Author

Nick Iyengar

Nick Iyengar is an Associate Director of Digital Intelligence at Cardinal Path, where he is responsible for helping his clients improve their profitability by building their analytics capabilities. He recently returned to Cardinal Path for his second tour of duty, having completed his MBA at the University of Michigan Ross School of Business last year. At Cardinal Path, Nick has led Google Analytics implementations for dozens of organizations in a wide variety of industries. Prior to joining Cardinal Path, Nick began his career in digital analytics at Google, where he managed Google’s Analytics Guru team.