Everyone’s level of comfort with data visualization is different. You may engage with end users who already are advocates. These people will come to you with new ideas and tips for improving your output, and ideally they will act as champions for your work. Others are not so engaged because they may not prefer to look at dashboards and have their own ways to lay out and analyze data. So how do you bring disengaged colleagues over the line to become your advocates? 

Enter the Change Team

What is a change team? It’s a group of data analysts who work with end users on a regular basis, using data dashboards as learning tools along the way. With a well-planned change team initiative, you can almost immediately begin to:

  1. Help people understand which data assets are used (or not used) in a specific dashboard, and why
  2. Dig into design with users to determine whether the information they need is in a dashboard or hasn’t been included  
  3. Discuss whether design is speeding comprehension or if the UX is getting in the way  
  4. Pilot test new dashboards that you haven’t released to your broader organization and enhance them before you do
  5. Conduct regular follow-ups with users to actively manage adoption and drive continuous improvement


Every time we start a new data initiative, we begin by meeting with a change team that includes colleagues from the part of the business we’re serving to understand their pain points and discuss what we’re trying to solve. It’s a great idea to have UX colleagues in the room in this meeting so we can work closely together to sketch the concepts and wireframes and then walk through them as a team. 


Interrogating the Widget

An example discussion guide from a success team often goes something like this:

  • “Let’s talk about this widget in the dashboard. Tell me what you see?”
  • “What would you do with that widget?”
  • “What does this widget tell you?”
  • “What do you think it should tell you?”

And so on. We hold these usability sessions before we even get to build a single widget, so that when we do, we know that the adoption will happen on the other side.


A complementary way to speed adoption is an online change team community (ours is called a success community), where end users can post input about new features or things they’d like to see improved. These always turn up good ideas and suggestions.


Measure What You Make

Regardless of how much time you spend up front with your change team, the adoption equation is incomplete without measurement and monitoring. As soon as a dashboard launches, we conduct a pilot over two to three months with the initial group of users who met with our change team. This is very helpful to determine what works, what doesn't work, and whether there is something that we can change. Usually when you have these people engaged earlier on, adoption becomes a nonissue because they feel they've been part of the process, they've been listened to, and then they become also champions of that dashboard. They will go and tell everyone, “Look at this tool. It's great.”


We also have identified a number of dashboards that we constantly monitor to see which sections are used and not used, what people are looking at, which kinds of pages are most popular, which tabs are being used most frequently, and so on. Hit maps of teams we serve across the company give us status updates (green, yellow, and red) based on which teams are using key applications the most versus the least. See a team that has gone completely red and isn’t using your dashboards? It’s a great opportunity for the change team to reach out and ask, “Why are you not using the tools that we’ve made available to you? Do you need training or some other kind of support?”


Overall, the uptake of our dashboards has been great, and I believe three keys to that adoption are our up-front change team sessions, our dashboard piloting and our adoption dashboards. These tools create a constant feedback loop that means we’re always focused on continuous improvement.