How to select the right data for your dashboard
The most important aspect of designing an effective dashboard is making sure you have selected the right metrics and KPI’s to display. No matter how stunning or clever a visual design is, if it isn’t displaying meaningful insights and data relevant to its audience it will just end up being a pretty display that no one looks at.
This article will show you some proven techniques that will help you to collect and define appropriate performance indicators for executive and operational dashboards. While the techniques discussed here are focused on dashboard design, these same principles can be used across many different business intelligence requirements gathering efforts.
With the prevalence of dashboard tools and displays seen in widely varied software offerings, people have different understandings of what a dashboard, metric, and key performance indicator (KPI) consist of. To make sure we are all speaking the same language, I will define a set of terms that will form the basis of our design discussion.
Metrics and Key Performance Indicators
Metrics and KPIs are the building blocks of many dashboard visualizations; as they are the most effective means of alerting users as to where they are in relationship to their objectives. The definitions below form the basic building blocks for dashboard information design and they build upon themselves so it is important that you fully understand each definition and the concepts discussed before moving on to the next definition.
Measure: A measure is numerically quantifiable piece of data. Sales, Profit, Retention Rate, are all examples of specific measures.
Dimension: A dimension represents different facets of a given measure. For instance, time is often used as a dimension to analyze different measures. Some other common dimensions are region, product, division, market segment, etc.
Hierarchy : Dimensions can be further broken down into hierarchies. For instance the time dimension may also form a hierarchy such as Year > Quarter > Month > Day.
Grain: Each of level within the hierarchy is referred to as the grain of the dimension. For example, if you were looking at a Geography dimension, the individual grains (levels) might be Region > Country > State/Province > City > Postal Code
Metric: A metric, which is the type of data we are often displaying in a dashboard, is a measure that represents a piece of data in relationship to one or more specific dimensions and associated grains.
Gross Sales by Week is an example of a metric. In this case, the measure would be dollars (gross sales) and the dimension would be time with the associated grain (week.)
Looking at a measure across more than one dimension such as gross sales by territory and time is called multi-dimensional analysis. Designing dashboards for multi-dimensional analysis can add significant complexity to your dashboard design and user experience due to the fact we are using a two dimensional surface (device screen) to represent multiple dimensions. While there are effective layout and interaction patterns to handle this type of analysis, it is important to make note of that prior to your design phase as these types of designs require more sophisticated approaches.
Key Performance Indicators (KPI): A KPI is simply a metric that is tied to a target. Most often a KPI represents how far a metric is above or below a pre-determined threshold. KPI’s usually are shown as a ratio of actual to target and are designed to instantly let a business user know if they are on or off their plan without the end user having to consciously focus on the metrics being represented.
For instance, we might decide that in order to hit our quarterly sales target we need to be selling $10,000 of widgets per week. The metric would be widget sales per week, the target would be $10,000. If we used a percentage gauge visualization to represent this KPI and we had sold $8,000 in widgets by Wednesday, the user would instantly see that they were at 80% of their goal.
When selecting targets for your KPI’s, you need to remember that a target will have to exist for every grain you want to view within a metric. Having a dashboard that displays a KPI for gross sales by day, week, and month will require that you have identified targets for each of these associated grains.
Scorecards, Dashboards, and Reports
The difference between a scorecard, dashboard, and report can be one of fine distinctions. Each of these tools can combine elements of the other, but at a high level they all target distinct and separate levels of the business decision making process.
Scorecards: Starting at the highest, most strategic level of the business decision making spectrum, we have scorecards. Scorecards are primarily used to help align operational execution with business strategy. The goal of a scorecard is to keep the business focused on a common strategic plan by monitoring real world execution and mapping the results of that execution back to a specific strategy. The primary measurement used in a scorecard is the key performance indicator. These key performance indicators are often a composite of several metrics or other KPIs that measure the organizations ability to execute a strategic objective. An example of a scorecard KPI would be an indicator named “Profitable Sales Growth” that combines several weighted measures such as: new customer acquisition, sales volume, and gross profitability into one final score.
Dashboards: A dashboard falls one level down in the business decision making process from a scorecard; as it is less focused on a strategic objective and more tied to specific operational goals. An operational goal may directly contribute to one or more higher level strategic objectives. Within a dashboard, execution of the operational goal itself becomes the focus, not the higher level strategy. The purpose of a dashboard is to provide the user with actionable business information in a format that is both intuitive and insightful. Dashboards leverage operational data primarily in the form of metrics and KPIs.
Reports: Probably the most prevalent BI tool seen in business is the traditional report. Reports can be very simple and static in nature, such as a list of sales transaction for a given time period, to more sophisticated cross-tab reports with nested grouping, rolling summaries, and dynamic drill-through or linking. Reports are best used when the user needs to look at raw data in an easy to read format. When combined with scorecards and dashboards, reports offer a tremendous way to allow users to analyze the specific data underlying their metrics and key performance indicators.
Gathering KPI and Metric Requirements for a Dashboard:
Traditional BI projects will often use a bottom-up approach in determining requirements, where the focus is on the domain of data and the relationships that exist within that data. When collecting metrics and KPIs for your dashboard project you will want to take a top-down approach. A top-down approach starts with the business objectives and decisions that need to be made first and then works its way down into the data needed to support those decisions.
In order to take a top down approach you MUST involve the actual business users who will be utilizing these dashboards, as these are the only people who can determine the relevancy of specific business data to their decision making process.
When interviewing business users or stakeholders, the goal is to uncover the metrics and KPI’s that lead the user to a specific decision or action. Sometimes users will have a very detailed understanding of what data is important to them, and sometimes they will only have a high level set of goals. By following the practices outlined below, you will be able to distill the information provided to you by the user into a specific set of KPIs and metrics for your dashboards.
Interviewing Business Users:
In our experience working directly with clients and gathering requirements for executive and operational dashboard projects in a variety of industries, we have found that the interview process revolves around two simple questions: “What business questions do you need answers to, and once you have those answers what action would you take or what decision would you make?”
Question 1: “What business questions do you need answers to?”
The purpose here is to help the business user define their requirements in a way that allows us to get to the data behind their question. For instance, a VP of sales might have the question: “Which sales people are my top producers?” or “Are we on target for the month?” In the case of the question “Which sales people are my top producers?” we might then follow up with a couple of questions for the VP and ask her “Would this measure be based on gross sales? Would you like to see this daily, weekly, or monthly?”
We want to identify the specific data components that will make up the KPI or metric. So we need to spend enough time with the user discussing the question until we clearly understand the measure, dimension, grain, and target (in the case of a KPI) that will be represented.
Question 2: “Based on the answer to Question 1, what other questions would this raise or what action would you take?”
Once we understand the metric or KPI that is needed to answer the user’s question, we then need to find out if the user would want to perform further analysis based on that answer, or if they would be able to take an action or make a decision. The goal is to have the user keep breaking down the question until they have enough information to take action or make a decision. This process of drilling deeper into the question can be analogous to peeling back the layers of an onion; we want to keep going deeper until we have gotten to the core, which in this case is the user’s ability to make a decision or take action.
As a result of this iterative two part question process we are going to quickly filter out the metrics and KPIs that could be considered just interesting from the ones that are truly critical to the user’s decision making process. This approach is counter to what I call the “kitchen sink approach” to dashboard development, where the product and/or engineering team design a dashboard with every available piece of data and complex widgets that will allow the user to search, filter, and or drill their way into the data they need.
Taking a kitchen sink approach to dashboard design will more often than not just overwhelm your users with too many choices and cognitive load that results in a dashboard that does not get used. Conversely, presenting data that is tightly targeted to what a user needs to see and make decisions on to improve the business condition will result in a highly effective and widely used dashboard.
Putting it all together — The KPI Wheel
In order to help with this requirements interview process, I have created a simple tool called the KPI Wheel. The interview process is very rarely a structured linear conversation, and more often is an organic free-flowing exchange of ideas and questions. The KPI Wheel allows us to have a naturally flowing conversation with the end-user while at the same time keeping us focused on the goal of gathering specific requirements.
I recommend printing out the image below on several pieces of paper and having them handy for your user interviews where you can write your notes directly on the wheel. You can right click on image and open in new browser window to print.The KPI Wheel is tool that can be used to collect all the specific information that will go into defining and visualizing a metric or KPI. We will use this tool to collect the following information:
The business question that we are trying to help the user answer.
Which business users this question would apply to.
Why the question is important to business objectives.
Where data resides to answer this question.
What further questions this metric or KPI could raise.
What actions or decisions could be taken with this information
Start anywhere, but go everywhere
The KPI Wheel is designed as a circle because it embodies the concept that you can start anywhere but go everywhere, thus covering all relevant areas. In the course of an interview session you will want to refer to the wheel to make sure you are filling in each area, as they are discussed. As your conversation flows you can simply jot down notes in the appropriate section, and you can make sure to follow up with more questions if some areas remain unfilled. The beauty behind this approach is that a user can start out very high level “I want to see how sales are doing” or at a very low level “I need to see product sales broken down by region, time, and gross margins.” In either scenario, you are able to start at whatever point the user feels comfortable and then move around the wheel filling in the needed details.
Question 1: What’s The Question?