Drew Warren

Managing Analyst

Building a dashboard seems like a no-brainer. Dashboards enable users to standardize KPIs and benchmarks across the organization, streamline data collection, and reduce the effort required to access and incorporate data into decision making. However, a dashboard’s success hinges on more than data consolidation, visualizations, or rich functionality; ultimately it is dependent upon end-user adoption. Without buy-in and ongoing usage from end-users, a dashboard runs the risk of going unutilized, wasting the time and resources that were used to develop it.

From the most basic versions such as built-in spreadsheets, to robust instantiations leveraging enterprise-grade data aggregation and visualization platforms, dashboards require end users to develop a familiarity with a new method of getting data. As with any new technology, enabling them to quickly identify the value within the dashboard will speed up adoption. Setting realistic expectations about what the dashboard is capable of, and how it will develop over time also increases adoption, especially during the initial rollout when some or even most of the dashboard may still be in development.

These adoption-driving objectives are best addressed in the dashboard planning phase by working with end-user stakeholders to define requirements aligned with three aspects: Visual Simplicity, Depth of Data, and Unique Data. By giving stakeholders an opportunity to provide input in these areas, you can develop a dashboard that will constantly provide value, meet or exceed expectations, and most importantly, generate high adoption among end-users.

Keys to Dashboard Adoption

Visual Simplicity

A successful dashboard provides end-users with the information they want and need at a glance, while offering clear next steps on how to dig deeper. Though this may seem obvious, dashboard projects often go off the rails with too many visualizations and overly complex functionality that confuse end-users, reducing adoption. Two common issues that lead to overly-complicated dashboards are:

  • Over-emphasis on metrics during planning
  • Too little adherence to end-user wants and needs during planning

In the first case, people, especially analysts, approach dashboard planning by considering all the potential metrics and dimensions that could be visualized. However, when end-user stakeholders are presented with the mass of available metrics, they can find it difficult to rationalize the ones that are critical to their work and are likely to select “D, all of the above”. This leads to a complex set of requirements that dilute the dashboard’s focus on providing key information, while increasing the time it take to develop.

In the second case, building a complex web of interconnected data sources and visualizations that enable data to be cross-referenced, filtered, and efficiently analyzed in great detail is an analyst’s dream project. This desire to build a holistic solution right out of the gate can lead to far more complex requirements and an aggressive focus on data aggregation, which can delay development or lead to initial iterations that fail to address end-user wants and needs.

To ensure visual simplicity, keep things as simple as possible. Focus on identifying end-user wants and needs, then define the dashboard requirements to fit them. This puts the emphasis on developing a view that quickly displays the information end-users are looking for, which will positively impact adoption rates.

Depth of Data

With the ubiquity of stand-alone and embedded analytics available from web, social, email, CRM, and media platforms, end-users have become accustomed to digging deeper into data. During the development process it can be tempting to create a similar level of depth within the dashboard that people are used to seeing in these analytics offerings. However, it is important to remember that meeting end-user wants and needs, does not simply mean replicating functionality and views found in other platforms.

Working with end-user stakeholders to identify the right level of depth is about proactively uncovering common questions they may have when reviewing data in the dashboard and deciding whether to develop features and functionality that can answer them, or direct users to other analytics solutions. Developing a bright line between when users should use the dashboard and when they should dig into a platform’s analytics to answer their questions will limit dashboard requirements and help set expectations that increase end-user adoption.

Unique Data

The ability to see data from multiple channels in a single location is often highlighted by end-users as a significant benefit provided by dashboards. While this is true, this benefit will only drive adoption if the information the dashboard provides is useful to them. One way to ensure your dashboard provides end-users with valuable information and data is to incorporate views that cannot be found elsewhere.

There are many ways to develop unique data and views for dashboards, but two primary ones are: focusing on cross-channel data, and working with end-users to create or identify and visualize data linked by unique characteristics such as a post-tagging taxonomy, or custom audience segments. Including unique data or views will help highlight the dashboards value to end-users and prevent it from simply replicating information available elsewhere, ultimately increasing adoption.

Three Ideas to Ensure End-User Adoption

Including end-users early in the requirements development process will significantly increase your chances of generating adoption. One way to do this is to hold a workshop and facilitate brainstorming exercises that enable you to identify:

  • Key information end-users are looking for (visual simplicity)
  • The target audience for the dashboard (depth of data)
  • Opportunities to create data and views that cannot be found elsewhere (unique data)

The following tips may be helpful to consider when preparing for any workshop with end-users:

  1. Focus on questions and insights: Build your workshop around identifying the questions, information, and insights end-users are interested in rather than focusing on specific metrics.
  2. Distinguish between dashboards and research: During the workshop, keep an eye out for questions that would be better answered through one-off research projects as opposed to those that require regular reporting and belong in the dashboard.
  3. Get end-user buy-in on requirements: Designate time after the workshop to review requirements with end-users before starting development. This provides an opportunity to reflect their input and share your interpretation of the metrics and views that will be most beneficial.

Drew Warren

Managing Analyst