Know Your Audience

This is part two of a series on dashboard visualization.

Before you build a dashboard, you have to know your audience.  If you don’t know who your viewers will be and where their interests lie, you run the risk of building a dashboard which fails to serve their needs.  When that happens, people stop looking at your dashboard.  In order to increase the likelihood that your dashboard will be useful, I have a few critical questions:

1. Who is your intended audience?
2. How will your intended audience use your dashboard?
3. What actions do you want them to take as a result of what they see?
4. Are you showing the right measures in the right way?
5. What cultural differences might matter?

The rest of this post will drill into each of these concepts.

Your Intended Audience

In the previous post, I mentioned that my CEO probably wouldn’t be interested in my API metrics dashboard:

Even though it’s pretty straightforward, this dashboard wouldn’t serve my CEO’s needs.

This leads me to thinking about the intended audience.  Some potential intended audiences for a business dashboard include:

• Technical specialists or line operators
• Low-level or mid-level management
• Upper-level management
• C-level management
• The board
• External regulators or auditors
• The general public

Each of these roles cares about different measures and typically wants to see data displayed in different ways.  People at the top of the list—technical specialists and low-level managers—tend to want to see the most data as numbers.  They can use their hard-earned contextual information to translate a number or set of numbers into actions.  For example, in my API dashboard above, I can see that 95% of my API requests will return within 16.64ms.  Owning that API, I know whether 16.64ms is fast enough.  The line chart on the right shows me a day-by-day breakdown of performance, and I can see if there are any radical changes which deserve my attention.

That context is vital; if I show someone without that context this dashboard, that person will be able to get some information and might be able to say that things are going fine (because we don’t see any major spikes in response time and 500 category errors are rare), but might not know if this API is meeting business needs with respect to response time.

That context is also something that we lose as we move down the list of audiences—as you move to higher levels of an organization and especially outside of the organization, people will have less of the context needed to decipher a chart like the one above.  Instead, we want to use different measures and often in different ways than what I showed in the dashboard above.  We want to find the things which make sense to these actors and show them in a way which makes it easy to get an idea of what’s happening.  For example, external auditors might be interested in the number of production changes which followed the proscribed change control process, the number which were emergency fixes, and the number which happened outside of the process.  Displaying those measures over time can give a regulator an idea of whether the company is following procedures or if something has changed—if the process has gone out of control.

One final thing I should stress here is that you can have more than one audience for a dashboard.  The splits I mentioned above were examples of people who play specific roles, but you wouldn’t necessarily have a separate dashboard for an individual accountant versus the accounting manager.  This has its positive and negative aspects:  it’s positive in that you can serve more people with the same dashboard(s), but negative in that sometimes your audiences’ interests will collide and you may need to choose between serving those of one group versus those of another.

Your Audience’s Intended Use

Your job as a dashboard creator is to provide relevant metrics in an easy-to-understand way.  If you succeed at your job, the user will get relevant information as easily as possible in order to make good business decisions.  There are a few questions along these lines which you should think about as you design a dashboard.

First, do users need to see historical data or just the present value?  There are cases where just the present value is fine:  a measure like Days Without An Accident makes sense on its own and does not need historical context.  By contrast, quarterly revenue is a measure that we want to collect and display historically:  if your Q4 revenue is $2 million, that by itself doesn’t tell much.  Paired with a target, it tells us more information, but we get even more detail if we can see Q1-Q3, as well as Q4 of last year.  Those additional pieces of information add a great deal of context to the Q4 revenue figure and tell us if $2 million is a good quarter or a bad one.

In addition to historical data, I also mentioned the second question:  is there a baseline or known good value?  If there is, we should mark it somehow.  In my dashboard above, I mentioned that I know 16.64ms is acceptable for a 95th percentile, but it would be even better if I laid out a target.  Let’s say that the 95th should be within 25ms.  Simply having another card denoting a target of 25ms will give readers that much more context, to say that we’re beating our target.  With the example of days without an accident, you could match it up with a target or the best value over the past year or something else to give it more context, but you don’t need to show the history of that measure.

The third question that I want to ask here is, under which circumstances should a user act?  Let’s suppose that we have a real-time, operational dashboard for manufacturing, and that dashboard shows the number of defects in samples over time.  We can plot out percentage of defects over time, and we might have a rule that we stop the manufacturing line if a single sample has more than 5% defects unless there is some overriding concern.  Knowing that rule, we can put a line or some other indicator at 5% to tell an operator that there is trouble.  That way, an operator could determine if it makes sense to shut down the line given an entry outside of the acceptable bounds.

The last question for this section is, what media will your audience use to view the data?  Maybe your CEO looks at the quarterly revenue dashboard from his phone while on his way between meetings.  Perhaps your board members get monthly net margin updates on their iPads.  And then there are the sysadmins with 32″ screens where they can slice and dice server-level metrics to see if something has gone wrong.  Maybe your development team has a TV with the current build status.  Each one of these form factors will lead to different methods of interaction and different levels of comfort in playing around with results.  You can do some minor filtering and drilling on a phone or tablet, but you don’t want them to type.  Desktops are more suited for data dumps and table-heavy dashboards, while TVs should have just a few metrics with big fonts and no requirement to click, scroll, or otherwise mess with the dashboard once it’s installed.

Show The Right Measures In The Right Way

Let’s imagine a sales team dashboard.  There are some important measures you want to include in a sales team dashboard, and you can get some of these from conversations with the sales team and sales team lead.  Some of the measures might include:

1. How many leads does the sales team have?
2. At which phase in the sales pipeline are these leads?
3. What is the probability of each lead turning into a sale?
4. If a lead turns into a sale, how much is that worth?
5. How many sales has each salesman recorded?
6. What is each salesman’s quota?

We wouldn’t want to include measures like server uptime, net margin, revenue, or number of high-severity tickets in JIRA.  Those are all important measures and some of them even relate tangentially to sales, but they don’t really belong on a sales team dashboard.

We can give some answers for several of these questions with a couple visuals:

Three visuals can answer several important sales pipeline questions.

These three visuals indirectly answer the first four questions and give an idea of how well the company is doing in acquiring customers.  We can see that there are a couple contacts for whom we have not yet set up an overview call, and a clump of customers who talked to a sales engineer but haven’t committed to purchase.  For each of these customers, we asked the salesman to mark the value of the purchase and the likelihood at this time that a customer would say yes.  Those numbers fluctuate and the $490K value should be taken with several grains of salt, but we’re giving the sales team lead a look at how his entire team is doing, and an experienced team lead can look at these numbers and determine if the pipeline is drying up or if things look good.

Cultural Differences

The last point I want to make in this section is that there are cultural differences which can affect how people interpret your visuals.  The most common thread for research is in interpretation of colors, such as this infographic on color by culture and Christina Wang’s discussion of symbolism of colors.

If you’re tailoring your dashboard for people in a particular culture, it can help to have some understanding of how factors like color choice can alter their interpretation of your dashboard.  That said, it’s possible to overstate the importance of these color selections.

Conclusion

In this section, I focused on things we should know about our intended dashboard viewers.  These questions will help us determine whether we want to build an operational dashboard, a strategic dashboard, or a tactical dashboard.  They will also help us figure out what people want to see.  Sometimes, like in the sales team example, you will need to convert those questions into “dashboardable” measures (especially when talking to people who live in spreadsheets all day), but this will give you a head start on building a quality dashboard.