Building Great Dashboards Series

Part 3: Solicit Feedback While Building a Dashboard

This is part three of our four-part series on building great dashboards.  If you have not read Part 1: Gathering Dashboard Requirements or Part 2: Creating a Dashboard Mock-Up, you may want to go back and read them.

In our previous blog post, we explained the importance of building a mock-up. In this post, we will explain the value of soliciting user feedback throughout the dashboard building process. You may be thinking that between the requirements meeting and the mock-up that you have spent quite enough time getting feedback, however, in our experience the best dashboards are created with feedback throughout the process. Despite gathering requirements and feedback on the mock-up, nothing is like showing users a working dashboard to get some great insights into their thinking and usage.

How to gather feedback

It is best to have short, weekly meetings with users to discuss the latest improvements to the dashboards and gather their thoughts. Below are some ideas on how to effectively use your time together.

See how users interact

When possible let the users see the dashboard, and watch how they interact with it. Try to refrain from explaining the dashboards and instead let users explore. This user exploration will help you identify what parts and pieces of the dashboard may be confusing and could require some adjustments. It may be helpful to give users a specific task, such as answering a question, and see how they navigate through the dashboards and respond. In our current remote environment, our team can send users a link to a dashboard and ask them to take a video of the screen as they try to answer the question. Be sure to ask users to think out loud so you can determine where any confusion is taking place or give tips for easier and more efficient ways to answer the question using the dashboards.

What if I have 25 users?

You don’t need to meet weekly with all users if there is a large group. Meeting with a few key users is fine, but make sure to have a check-in with the entire group midway through the project to make sure you have not veered too far off course. Also, feel free to pushback if you feel requests do not represent the entire group. If there are a few different “types” of users (for example if sales and marketing team members are using the same dashboard) then it is important that all the user types send a representative to the weekly meeting.

Watch out for HIPPOs! (Highly Paid Person’s Opinion)

Try to understand the dynamics of the team you are building a dashboard for. There may be a leader (a HIPPO) who will tell you exactly what they want to see, without taking into account what their team members need. At SIGMA we have found the best way to handle this is to build a separate view for the leader, which is at a higher level than what the rest of the team needs.

What to do with feedback

You are not the end-user

This is so important to remember that it bears repeating: you are not the end-user. (You do, however, have valuable knowledge that your end-user may not – more on that later). You have built a beautiful mock-up, gathered feedback, and agreed on the direction, but now users want to add a lot more filters to clutter things up or they want to add a data table that ruins the simplistic, visual design you were going for. They are destroying your beautiful project! Except they are not. They are trying to create a tool that is useful for them. Sometimes it is helpful to have fifteen filters on a dashboard – if it really solves a specific problem for a user, so be it. In addition, oftentimes having a data table available somewhere in the dashboard is useful for users who want to dive deeper.

Remember that you will not be using the final dashboard to answer questions and solve challenges. Your users will. When users ask for additions that are functional, but not beautiful err on the side of giving them those features.

But you can push back

It may sound like we are advocating for doing whatever users’ request, and we are suggesting that should be the default, but there are times to push back. You are more knowledgeable than your users about the data available and the best visualization techniques. Here are some examples of when to push back and share your point of view instead:

• Do not align with goals: Oftentimes users forget what specific goals this dashboard may have had. It is best to gently remind users of that, and let them know what they are requesting may be added in the future.
• Technical problems: Some things just cannot be done given the data you have and the software you are using. You should also push back if they are asking for things that may slow down the dashboard.
• Build what your users need, not what they want: People often want flashy dashboards that look fun to use, but often what they need is just a few standardized reports to help them get through their day. No one opens up dashboards for the fun of it – they are trying to solve a problem quickly and move onto the next task.

At the end of this process, hopefully you have dashboards you are proud of and that users are excited to start using. In the fourth, and last, part of our series we will explain what to do once the dashboards are launched.