6 Steps to Troubleshoot Tableau Dashboards. In-Depth Troubleshooting Guide for Data Analysts to Confirm Data & Reports are Accurate & Up-to-Date.
Want to Deploy a Successful Dashboard? Ask These 3 Questions First.
Understanding the Needs of the Stakeholder Helps You Deploy a Successful Dashboard. Learn How to Ask the Right Questions & Streamline Your Requirements.
As a data analyst, business intelligence analyst, or similar data practitioner at the individual contributor level, it’s likely that part of your job involves creating data dashboards. Depending on the stakeholders involved and your organization’s process for gathering requirements for new dashboards (if you have a process), your understanding of the business needs may or may not match the stakeholder’s understanding of the business needs. I’m here to help you streamline the requirements-gathering process, understand the needs of the dashboard users, and deliver a product that meets those needs.
The Purpose of Dashboards
Data analytics and data science are relatively new disciplines compared with computer science in general, and the terminology of the world of data is ever-evolving, which sometimes causes confusion. Data dashboards are ubiquitous, so your colleagues may not feel comfortable asking questions about them. Let’s get on the same page, and be sure to get on the same page with your stakeholders, too, before you start doing any development work.
A dashboard’s purpose is to provide insight into the business as a whole, a department, or a process in an interactive manner. A static report or static data visualization is not a dashboard, even if the design makes it look like one. Well-executed dashboards provide a window into the health of the business, department, or process in a way that allows for quick identification of trends, patterns, and change. Generally, dashboards are built in a business intelligence tool such as Tableau, Microsoft Power BI, Qlik, Domo, or Looker.
Depending on your organization, there may or may not be a formal process for gathering requirements for new dashboards, and the amount of information provided to you at the time the development task is assigned may vary greatly. If the information you’re given does not answer the following questions, you should consult with the stakeholder requesting the dashboard. If that is not allowed due to company policies or seems like it might violate unspoken norms, consult with your manager about the need to obtain more information.
Now that we’ve established a common understanding of what a dashboard is and understand that organizations’ approaches to dashboard development vary, let’s explore the three most important questions you need to answer in order to develop and deploy a successful dashboard.
For illustration purposes, consider the following use case I encountered in the wild recently. I was asked to create a dashboard with the data exported from our service management platform to a cloud storage solution. For context, my company uses Atlassian’s product Jira Service Management to track, assign, and status requests from product users related to problems with our products, new feature requests, and access issues, among others.
If you’re not familiar with Jira or another service management tool like ServiceNow or Zendesk, think of the last time you emailed a company about a problem with their product or service. You probably got an automated email like one I received a few days ago after my puppy chewed through the power cord to my Smart Garden 9 PRO and I asked about getting a replacement.
If you’re a newer data analyst, it would be worth your while to get familiar with these tools and the types of data they collect and report.
And now for the three questions!
1. Who will be using the dashboard?
This is the most fundamental question. A dashboard you design for everyone in the company should be very different from one you design for executives. Hopefully, the stakeholder requesting the dashboard has provided this information, but don’t hold your breath. The dashboard’s audience will affect the specific metrics you’ll provide, the level of granularity of those metrics, and the assumptions you can make during development. Depending on the number of charts and metrics involved, you could design a dashboard with an executive view (perhaps for a Chief Product Officer), a manager view (for a Director of Customer Experience), and a team view (for the service desk agents to view their own performance), as I did recently.
2.What are the 3 to 5 most important questions the dashboard should answer?
Earlier in my career, I would’ve asked which metrics the stakeholder would like included. But I’ve since learned that stakeholders often do not know which metrics will answer their questions, or even which metrics are available or which are possible to calculate with the data available. Instead, I now ask which questions they need answers to, and I ask them to limit them to a maximum of five for a couple of reasons. First, if I provide data that answers their three most important questions, that data will likely answer other questions, too. Second, it’s hard to answer too many unique questions in one dashboard without it becoming unfocused or cluttered.
Let’s return to the service management use case and pretend I work at Click & Grow, the company that makes my Smart Garden. If I am developing the dashboard for the customer service manager, they will likely want to answer the following questions:
1. How many requests are we receiving per time period (day, week, month, etc.)?
2. How long does it take our service desk to resolve requests?
3. How does the time to resolution differ among the categories of requests?
4. Who are our best-performing service desk agents?
Once you start to dig into these questions, you’ll discover they nearly always produce additional questions. For instance, to determine the best-performing service agents, first we have to define what we mean by “best-performing.” Did they receive the highest customer satisfaction scores? Solve issues assigned to them most quickly? Usually, it’s a combination of those two factors, but there could be others. If your organization does not already have a defined metric, it’s a good idea to come up with a proposal and run it by the stakeholder.
In order to create a dashboard that answers all four of the questions posed, we need to break the questions down into specific requirements. Here are just a few requirements we could take from our use case:
- The distinct count of issues submitted via the service management system
- The date and time the service desk started working on the issue
- The date and time the service desk resolved the issue, or if they couldn’t resolve it, the date and time they escalated it to another team (the definition of “resolved” should be established, too)
- The distinct count of each issue type. For our use case these might include (but are not limited to):
a. App access issues like a customer being unable to log in
b. Equipment issues like the lamp on the customer’s Smart Garden has stopped working
c. Subscription inquiries such as requests to cancel plant seed subscriptions, change the frequency of delivery, or change to a different subscription plan
d. Website issues such as an error message when the customer clicks a link to a product page
It quickly becomes apparent that our initial list of four questions provided by the stakeholder actually involves numerous metrics. The more important metrics usually have associated key performance indicators (KPIs) that you’ll want to display prominently with BANs (big ass numbers), sparklines, or other easily ingestible chart elements.
3. Are there published dashboards that you find especially helpful? If so, why? Are there others that are not helpful? Why?
This line of questioning helps me get a sense of what the stakeholder’s expectations might be, which chart types help them understand the data, and what their level of data literacy might be. I avoid questions like, “Do you prefer a bar chart or a line chart?” because those are decisions you should make based on the data and how you can show it most clearly. You are the data visualization expert, so don’t open the door to very specific requests that may not be the most effective method of communicating the data.
Asking these three fundamental questions will clarify the needs and expectations of the stakeholder, solidify your understanding of what is being measured, and inform your chart and design choices. Don’t be surprised if these questions lead to more questions or a lengthier dialogue. That’s a good thing! Those conversations are valuable opportunities for you to understand the business, the stakeholders, and the data more thoroughly, as well as being opportunities to educate the stakeholders about the data and to encourage them to think through their needs prior to requesting their next dashboard.
Build Successful Dashboards with Mighty Canary
Interested in trying it out for yourself? Send us your email and get started for free.