Chapter 1
In This Chapter
Comparing dashboards to reports
Getting started on the right foot
Dashboarding best practices
In his song “New York State of Mind,” Billy Joel laments the differences between California and New York. In this homage to the Big Apple, he implies a mood and a feeling that come with thinking about New York. I admit it’s a stretch, but I’ll extend this analogy to Excel — don’t laugh.
In Excel, the differences between building a dashboard and creating standard table-driven analyses are as great as the differences between California and New York. To approach a dashboarding project, you truly have to get into the dashboard state of mind. As you’ll come to realize in the next few chapters, dashboarding requires far more preparation than standard Excel analyses. It calls for closer communication with business leaders, stricter data modeling techniques, and the following of certain best practices. It’s beneficial to have a base familiarity with fundamental dashboarding concepts before venturing off into the mechanics of building a dashboard.
In this chapter, you get a solid understanding of these basic dashboard concepts and design principles as well as what it takes to prepare for a dashboarding project.
It isn’t difficult to use report and dashboard interchangeably. In fact, the line between reports and dashboards frequently gets muddied. I’ve seen countless reports referred to as dashboards just because they included a few charts. Likewise, I’ve seen many examples of what could be considered dashboards but have been called reports.
Now, this may all seem like semantics to you, but it’s helpful to clear the air and understand the core attributes of what are considered to be reports and dashboards.
The report is probably the most common application of business intelligence. A report can be described as a document that contains data used for reading or viewing. It can be as simple as a data table or as complex as a subtotaled view with interactive drill-downs, similar to Excel’s Subtotal or Pivot Table functionality.
The key attribute of a report is that it doesn’t lead a reader to a predefined conclusion. Although reports can include analysis, aggregations, and even charts, reports often allow for the end users to apply their own judgment and analysis to the data.
To clarify this concept, Figure 1-1 shows an example of a report. This report shows the National Park overnight visitor statistics by period. Although this data can be useful, it’s clear this report isn’t steering the reader toward any predefined judgment or analysis; it’s simply presenting the aggregated data.
A dashboard is a visual interface that provides at-a-glance views into key measures relevant to a particular objective or business process. Dashboards have three main attributes:
Figure 1-2 illustrates a dashboard that uses the same data shown in Figure 1-1. This dashboard displays key information about the national park overnight-visitor stats. As you can see, this presentation has all the main attributes that define a dashboard. First, it’s a visual display that allows you to quickly recognize the overall trending of the overnight-visitor stats. Second, you can see that not all the detailed data is shown here — you see only the key pieces of information relevant to support the goal of this dashboard, which in this case would be to get some insights on which parks would need some additional resources to increase visitor rates. Finally, by virtue of its objective, this dashboard effectively presents you with analysis and conclusions about the trending of overnight visitors.
Imagine that your manager asks you to create a dashboard that tells him everything he should know about monthly service subscriptions. Do you jump to action and slap together whatever comes to mind? Do you take a guess at what he wants to see and hope it’s useful? These questions sound ridiculous, but these types of situations happen more than you think. I’m continually called to create the next great reporting tool but am rarely provided the time to gather the true requirements for it. Between limited information and unrealistic deadlines, the end product often ends up being unused or having little value.
This brings me to one of the key steps in preparing for dashboarding: collecting user requirements.
In the non-IT world of the Excel analyst, user requirements are practically useless because of sudden changes in project scope, constantly changing priorities, and shifting deadlines. The gathering of user requirements is viewed to be a lot of work and a waste of valuable time in the ever-changing business environment. But as I mention at the start of this chapter, it’s time to get into the dashboard state of mind.
Consider how many times a manager has asked you for an analysis and then said “No, I meant this.” Or “Now that I see it, I realize I need this.” As frustrating as this can be for a single analysis, imagine running into it again and again during the creation of a complex dashboard with several data integration processes. The question is, would you rather spend your time on the front end gathering user requirements or spend time painstakingly redesigning the dashboard you’ll surely come to hate?
The process of gathering user requirements doesn’t have to be an overly complicated or formal one. Here are some simple things you can do to ensure you have a solid idea of the purpose of the dashboard.
Chances are your manager has been asked to create the reporting mechanism and he has passed the task to you. Don’t be afraid to ask about the source of the initial request. Talk to the requesters about what they’re asking for. Discuss the purpose of the dashboard and the triggers that caused them to ask for a dashboard in the first place. You may find, after discussing the matter, that a simple Excel report meets their needs, foregoing the need for a full-on dashboard.
If a dashboard is indeed warranted, talk about who the end users are. Take some time to meet with a few of the end users to talk about how they’d use the dashboard. Will the dashboard be used as a performance tool for regional managers? Will the dashboard be used to share data with external customers? Talking through these fundamentals with the right people helps align your thoughts and avoids the creation of a dashboard that doesn’t fulfill the necessary requirements.
Most dashboards are designed around a set of measures, or key performance indicators (KPIs). A KPI is an indicator of the performance of a task deemed to be essential to daily operations or processes. The idea is that a KPI reveals performance that is outside the normal range for a particular measure, so it therefore often signals the need for attention and intervention. Although the measures you place into your dashboards may not officially be called KPIs, they undoubtedly serve the same purpose — to draw attention to problem areas.
The measures used on a dashboard should absolutely support the initial purpose of that dashboard. For example, if you’re creating a dashboard focused on supply chain processes, it may not make sense to have human resources head-count data incorporated. It’s generally good practice to avoid nice-to-know data in your dashboards simply to fill white space or because the data is available. If the data doesn’t support the core purpose of the dashboard, leave it out.
I sometimes take this a step further and actually incorporate the component questions into a mock layout of the dashboard to get a high-level sense of the data the dashboard will require. Figure 1-3 illustrates an example.
Each box in this dashboard layout mockup represents a component on the dashboard and its approximate position. The questions within each box provide a sense of the types of data required to create the measures for the dashboard.
When you have the list of measures that need to be included on the dashboard, it’s important to take a tally of the available systems to determine whether the data required to produce those measures is available. Ask yourself the following questions:
These are all questions you need answered when negotiating dashboard development time, data refresh intervals, and change management.
If your organizational strategy requires that you collect and measure data that is nonexistent or not available, press Pause on the dashboard project and turn your attention to creating a data collection mechanism that will get the data you need.
In the context of reporting, a dimension is a data category used to organize business data. Examples of dimensions are Region, Market, Branch, Manager, or Employee. When you define a dimension in the user requirements stage of development, you’re determining how the measures should be grouped or distributed. For example, if your dashboard should report data by employee, you need to ensure that your data collection and aggregation processes include employee detail. As you can imagine, adding a new dimension after the dashboard is built can get complicated, especially when your processes require many aggregations across multiple data sources. The bottom line is that locking down the dimensions for a dashboard early in the process definitely saves you headaches.
Along those same lines, you want to get a clear sense of the types of filters that are required. In the context of dashboards, filters are mechanisms that allow you to narrow the scope of the data to a single dimension. For example, you can filter on Year, Employee, or Region. Again, if you don’t account for a particular filter while building your dashboarding process, you’ll likely be forced into an unpleasant redesign of both your data collection processes and your dashboard.
If you’re confused by the difference between dimensions and filters, think about a simple Excel table. A dimension is like a column of data (such as a column containing employee names) in an Excel table. A filter, then, is the mechanism that allows you to narrow your table to show only the data for a particular employee. For example, if you apply Excel’s AutoFilter to the Employee column, you are building a filter mechanism into your table.
Many dashboards provide drill-down features that allow users to “drill” into the details of a specific measure. You want to get a clear understanding of the types of drill-downs your users have in mind.
To most users, drill-down feature means the ability to get a raw data table supporting the measures shown on the dashboard. Although getting raw data isn’t always practical or possible, discussing these requests will, at minimum, allow you to talk to your users about additional reporting, links to other data sources, and other solutions that may help them get the data they need.
A refresh schedule refers to the schedule by which a dashboard is updated to show the latest information available. Because you’re the one responsible for building and maintaining the dashboard, you should have a say in the refresh schedules — your manager may not know what it takes to refresh the dashboard in question.
While you’re determining the refresh schedule, keep in mind the refresh rates of the different data sources whose measures you need to get. You can’t refresh your dashboard any faster than your data sources. Also, negotiate enough development time to build macros that aid in automation of redundant and time-consuming refresh tasks.
When collecting user requirements for your dashboarding project, there’s a heavy focus on the data aspects of the dashboard: the types of data needed, the dimensions of data required, the data sources to be used, and so on. This is a good thing — without solid data processes, your dashboards won’t be effective or maintainable. That being said, here’s another aspect to your dashboarding project that calls for the same fervor in preparation: the design aspect.
Excel users live in a world of numbers and tables, not visualization and design. Your typical Excel analysts have no background in visual design and are often left to rely on their own visual instincts to design their dashboards. As a result, most Excel-based dashboards have little thought given to effective visual design, often resulting in overly cluttered and ineffective user interfaces.
The good news is that dashboarding has been around for such a long time that there’s a vast knowledge base of prescribed visualization and dashboard design principles. Many of these principles seem like common sense; even so, these are concepts that Excel users don’t often find themselves thinking about. Because this chapter is about getting into the dashboard state of mind, I break that trend and review a few dashboard design principles that improve the look and feel of your Excel dashboards.
Dashboard design expert Stephen Few has the mantra, “Simplify, simplify, simplify.” The basic idea is that dashboards cluttered with too many measures or too much eye candy can dilute the significant information you’re trying to present. How many times has someone told you that your reports look “busy”? In essence, this complaint means that too much is going on in the page or screen, making it hard to see the actual data.
Here are a few actions you can take to ensure simpler and more effective dashboard designs.
Admit it. You include as much information in a report as possible, primarily to avoid being asked for additional information. We all do it. But in the dashboard state of mind, you have to fight the urge to force every piece of data available onto your dashboards.
Overwhelming users with too much data can cause them to lose sight of the primary goal of the dashboard and focus on inconsequential data. The measures used on a dashboard should support the initial purpose of that dashboard. Avoid the urge to fill white space for the sake of symmetry and appearances. Don’t include nice-to-know data just because the data is available. If the data doesn’t support the core purpose of the dashboard, leave it out.
The key to communicating effectively with your dashboards is to present your data as simply as possible. There’s no need to wrap it in eye candy to make it more interesting. It’s okay to have a dashboard with little to no color or formatting. You’ll find that the lack of fancy formatting only serves to call attention to the actual data. Focus on the data and not the shiny happy graphics. Here are a few guidelines:
Dashboards, in general, should provide at-a-glance views into key measures relevant to particular objectives or business processes. This implies that all the data is immediately viewable on the one page. Although including all your data on one page isn’t always the easiest thing to do, there’s much benefit to being able to see everything on one page or screen. You can compare sections more easily, you can process cause-and-effect relationships more effectively, and you rely less on short-term memory. When a user has to scroll left, right, or down, these benefits are diminished. Furthermore, users tend to believe that when information is placed out of normal view (areas that require scrolling), it’s somehow less important.
But what if you can’t fit all the data on one sheet? First, review the measures on your dashboard and determine whether they really need to be there. Next, format your dashboard to use less space (format fonts, reduce white space, and adjust column and row widths). Finally, try adding interactivity to your dashboard, allowing users to dynamically change views to show only those measures that are relevant to them.
As I discuss earlier in this chapter, only measures that support the dashboard’s utility and purpose should be included on the dashboard. However, it should be said that just because all measures on your dashboard are significant, they may not always have the same level of importance. In other words, you’ll frequently want one component of your dashboard to stand out from the others.
Instead of using bright colors or exaggerated sizing differences, you can leverage location and placement to draw focus to the most important components on your dashboard.
Various studies have shown that readers have a natural tendency to focus on particular regions of a document. For example, researchers at the Poynter Institute’s Eyetrack III project have found that readers view various regions on a screen in a certain order, paying particular attention to specific regions onscreen. They use the diagram in Figure 1-4 to illustrate what they call priority zones. Regions with the number 1 in the diagram seem to have high prominence, attracting the most attention for longer periods. Meanwhile, number 3 regions seem to have low prominence.
You can leverage these priority zones to promote or demote certain components based on significance. If one of the charts on your dashboard warrants special focus, you can simply place that chart in a region of prominence.
There will undoubtedly be lots of numbers on your dashboards. Some of them will be in charts, and others will be in tables. Remember that every piece of information on your dashboard should have a reason for being there. It’s important that you format your numbers effectively to allow your users to understand the information they represent without confusion or hindrance. Here are some guidelines to keep in mind when formatting the numbers on your dashboards and reports:
It’s common sense, but many people often fail to label items on dashboards effectively. If your manager looks at your dashboard and asks you, “What is this telling me?” you likely have labeling issues. Here are a few guidelines for effective labeling on your dashboards and reports:
Before you send out your finished dashboard, it’s worth your time to step back and measure it against some of the design principles discussed in this chapter. Here are some key questions you can use as a checklist before distributing your dashboard.
Look at the information you are presenting and determine whether it meets the purpose of the dashboard identified during requirements gathering. Don’t be timid about clarifying the purpose of the dashboard again with your core users. You want to avoid building the dashboard in a vacuum. Allow a few test users to see iterations as you develop it. This way, communication remains open, and you won’t go too far in the wrong direction.
Take an honest look at how much information on your dashboard doesn’t support its main purpose. To keep your dashboard as valuable as possible, you don’t want to dilute it with nice-to-know data that’s interesting but not actionable.
Every dashboard has one or more key messages. You want to ensure that these messages are prominently displayed. To test whether the key messages in a dashboard are prominent, stand back and squint while you look at the dashboard. Look away and then look at the dashboard several times. What jumps out at you first? If it’s not the key components you want to display, you’ll have to change something. Here are a few actions you can take to ensure that your key components have prominence.
There is a big difference between updating a dashboard and rebuilding a dashboard. Before you excitedly send out the sweet-looking dashboard you just built, take a moment to think about the maintenance of such a dashboard. You want to think about the frequency of updates and what processes you need to go through each time you update the data. If it’s a one-time reporting event, set that expectation with your users. If you know it will become a recurring report, you’ll want to really negotiate development time, refresh intervals, and phasing before agreeing to any timetable.
A dashboard should clearly specify its scope and shelf life. That is to say, anyone should be able to look at your dashboard and know the period it’s relevant to and the scope of the information on the dashboard. This comes down to a few simple things you can do to effectively label your dashboards and reports.
It’s important to document your dashboard and the data model behind it. Anyone who has ever inherited an Excel worksheet knows how difficult it can be to translate the various analytical gyrations that go into a report. If you’re lucky, the data model will be small enough to piece together in a week or so. If you’re not so lucky, you’ll have to ditch the entire model and start from scratch. By the way, that troublesome Excel data model doesn’t even have to be someone else’s. I’ve actually gone back to a model that I built, and after six or so months I had forgotten what I had done. Without documentation, it took me a few days to remember and decipher my own work.
The documentation doesn’t even have to be hifalutin fancy stuff. A few simple things can help in documenting your dashboard.
Before you distribute your dashboard, you want to ensure that it’s user-friendly. It’s not difficult to guess what user-friendly means:
Nothing kills a dashboard or report faster than the perception that the data in it is inaccurate. It’s not within my capabilities to tell you how to determine whether your data is accurate. I can, however, highlight three factors establishing the perception that a dashboard is accurate:
3.147.75.117