Data Visualization for Specific Tasks

This first subcategory is by far the most important for businesses. In this scenario, the chart or graph is like a hammer or a screwdriver: a person or group of people is using it to perform a very specific task, to get a job done.

Think about a supply chain professional placing orders with vendors to keep raw materials in stock while minimizing inventory carrying costs. Or think about an investor deciding which assets in a portfolio to buy, sell, and hold on a particular day. Wouldn't they commonly use data visualizations to do these tasks?

In the case of such job aides, designing the tool to fit the exact user or users and the specific details of their task is critical. It's not unlike the process of designing any instrument or application. It's just another type of thing for which the principles of user interface design apply.

Whenever a data visualization is being used primarily as a tool, it's necessary to develop a deep understanding of four key elements in order to identify requirements and how to validate that they have been met:

• User: Who is the person or people who will be using it, what do they care about, and why do they care about those things?
• Task: What task or tasks do they need to get done, how often, what questions do they need to answer, or what information do they need to gather in order to do it well, both in terms of quality and timeliness?
• Data: What data is relevant to the job and what needs to be done to make use of it?
• Performance: How does the final deliverable need to behave in order to be useful, such as dimensions and resolution, or data refresh frequency?

Let's consider a simple illustrative scenario in which the chart choice and the way it's built don't exactly help a certain person do a specific task. Instead of dreaming up a fake business scenario and using some fabricated sales database (I really struggle with made-up data), I'll use a personal example just to demonstrate the point.

Every April 30, I hike to the top of Mount Si in North Bend, Washington, just outside of Seattle, where I live. As I've mentioned, I love spending time on the trails and just being around the trees and the views. I know, it's corny, but I feel like it helps me balance out the data-heavy, digital side of my life.

To be fair, though, I do wear a GPS watch and geek out on the trip stats when I get home. So I don't quite manage to leave behind my inner data nerd in the car at the trailhead. That's okay with me for now.

Why April 30? That was the day my father passed away in 2015. When I heard the news, I knew I needed to climb that mountain to clear my mind and just find a way to be with him somehow, some way. Whether he was or wasn't there isn't the point and doesn't really matter to me. He was there in my thoughts.

Wait, how does any of this relate to graphical gaffes or pitfalls or anything? Good question. I'm getting there. Thanks for indulging me.

It's May 3 as I'm writing this right now, and I just finished doing my annual remembrance pilgrimage a few days ago. It happened to be a particularly clear day, and I had a lot of work to get done later that day, so I wanted to start the hike while it was still dark and see if I could get to the top in time to catch the sunrise, which was to take place at 5:54 a.m. Last year when I went to do this hike, I left early in search of the sunrise as well, but there was a huge fog covering the top of the mountain. It was difficult enough to see the trail that morning, much less the horizon.

But last year's trip provided something of value to me for this time around: my trip stats, including a full record of the time, elevation gain, and distance traveled over the course of the trek.

So that's my starting point. Let's go through the four key elements to get our bearings:

1. User: Ben Jones, hiker and data geek extraordinaire
   • Cares about having an inspiring sunrise hike to the top of Mount Si
   • Why? To remember his father, get some exercise, and enjoy nature
2. Task: Get to the top of Mount Si at or just before sunrise
   • How often? Once per year
   • Answers/information needed?
   1. 1. What time will the sun rise on April 30 in North Bend, Washington?
      2. How long will it take to get to the top of Mount Si?
      3. How much buffer time is needed to account for variation in trip time?
   • What does success look like?
   1. 1. Arriving at the of the mountain before sunrise
      2. Not arriving more than 15 minutes before sunrise, to avoid a long, cold wait
3. Data: Sunrise info from search query, detailed Mount Si hiking stats from previous trek
   • Sunrise time is a single constant; no data prep needed
   • Historical trek stats can be obtained from watch app and/or fitness social network
   • Buffer time is a choice based on assumed variability in travel time
4. Performance: No data refresh needed; analysis based on static data only

I'll keep it simple and leave out of this example the time it takes me to drive from my house to the trailhead as well as the time it'll take me to get out of bed, fully dressed, and on the road. Those are the other pieces of information I'll need to set my alarm before going to bed. But for the purposes of this example, we'll stick with hike start time as our task and objective.

At this point, all I need from the visuals of my previous trip is a good idea of how long it will take me to get to the top of the mountain, which I can deduct, along with a 15-minute buffer, from the 5:54 a.m. sunrise time to determine the time I'll need to start on the trail.

A quick download of my data allowed me to recreate what I saw when I went to my online fitness portal, more or less (Figure 7.2).

As I looked at these charts, I realized that they didn't really allow me to get a good answer to my question. The dashboard gave me many helpful pieces of information – the total round-trip distance, the total time I was moving, as well as the total elapsed time (minus stationary resting time), and an elevation profile as a function of distance traveled. I knew I went up and came straight back, so I assumed that the trail to the top was close to 4 miles long, and I could see that I was moving at a pace of around 20 minutes per mile over the course of the entire trip. But I could also see that my pace was faster on the way down from the top, so I couldn't really rely on this variable to do some back-of-the-napkin math to determine the time to the top based on distance and velocity. Not at the level of precision I was looking for, anyway. There was too much of a chance I'd miss the 15-minute window of time I was shooting for between 5:39 a.m. and 5:54 a.m.

Now, this isn't intended to be a criticism of the fitness social network where I store my trip stats. While I was genuinely surprised that I didn't find a single chart with time on the horizontal x-axis, I'd have to acknowledge that they didn't exactly set out to design this dashboard for my specific task of determining when to start on the trail to catch a glimpse of the sunrise that morning.

That being said, I was able to download my stats and do a quick dashboard redesign in Tableau to better suit my needs. Doing so allowed me to see very quickly that I reached the top of the mountain almost exactly two hours after I left my car at the trailhead the previous year (Figure 7.3).

Notice that I added two new charts with time on the horizontal axis. The first shows a timeline of my altitude in the top left corner. The second shows a timeline of total distance traveled in the bottom left corner. The altitude timeline is most helpful in my specific scenario because it's immediately obvious how long it took me to get to the top – the x-value corresponding to beginning of the middle plateau of the curve – 2 hours.

On other hikes, however, there may be no mountain to climb. The path could just be a loop around a lake, or an “out-and-back” along the shore of a river. In such cases, altitude might not be as helpful to determine the time it would take to reach a certain point along the path between the start and the finish. For those cases, time on the x-axis and distance traveled on the y-axis – the bottom left chart – will enable me find to the amount of time it took to reach any point along the path.

This time-distance view also helps because it lets me visually identify any long periods of rest – horizontal portions of the line where time keeps going but distance doesn't. Maybe I stopped to read a book, or eat lunch, or take some photographs. In this instance, I can see clearly that the only time I really stopped moving was for about 30 minutes right after reaching the top of the mountain. I can't use horizontal sections of the time-altitude view for this same purpose because it's possible that a horizontal section of this line corresponds with a flat section of the trail where I was still moving but at a constant elevation.

So now I have the final variable for my equation – estimated ascent time – and I was able to complete my simple task to determine the time to leave my car at the trailhead in order to make it to the top in time for sunrise:

And how'd the sunrise hike go, after all that? Well, I slept through my alarm and didn't start on the trail until 8:00 a.m. So it goes. Next year, for sure.

Now this may seem like a strange approach to begin to describe graphical gaffes. In many ways, it wasn't even a gaffe at all. The social network designed their dashboard; it didn't happen to help me do a rather specific task. There's no horrendous pie chart with 333 slices, no ghastly packed bubble chart. Just a line chart and a map that didn't help me complete my task.

Notice I didn't go into detail about whether line charts or bar charts are the “right” choice in this instance, or whether a dual axis for the altitude and velocity line chart was kosher or not. I think those debates can tend to miss the point. In this case, what was needed was a line chart, but one with time as the x-axis rather than distance in miles. The problem wasn't the chart type. It was the choice of the variable mapped to one of the axes.

My goal in using this example is to illustrate that “good enough” is highly dependent on the details of the task our audience needs to perform. It would be easy to start listing off various rules of thumb to use when choosing charts. Others have certainly done that to great effect. But if you're building something for someone who needs to perform a certain task or tasks, the final product will have to stand the test of usage. Pointing to a data viz guru's checklist will not save you if your users can't get their job done.

Data Visualization for General Awareness

Some visualizations aren't built in order to help someone perform a specific task or function. These types of visualizations lack a direct and immediate linkage to a job, unlike the ones we just considered.

Think about the times you've seen a chart on a news site showing the latest unemployment figures, or a slide in a presentation by an executive in your company that shows recent sales performance. Many times you aren't being asked to take facts in those charts and use them to perform any specific action right then and there, or even in the near future, or at all. Other people might be using these same exact visuals in that way – as tools – but some people who see them don't need to carry out a function other than just to become aware, to update their understanding of the way things are or have been.

As presenters of data visualizations, often we just want our audience to understand something about their environment – a trend, a pattern, a breakdown, a way in which things have been progressing. If we ask ourselves what we want our audience to do with that information, we might have a hard time coming up with a clear answer sometimes. We might just want them to know something.

What pitfalls can we fall into when we seek to simply inform people using data visualizations – nothing more, nothing less? Let's take a look at a number of different types of charts that illustrate these pitfalls. We'll stick with a specific data set to do so: reported cases of crime in Orlando, Florida.³ I visited Orlando in 2018 to speak and train at a journalism conference, and I found this data set so that my audience could learn using data that was relevant to our immediate surroundings.

The data set on the city of Orlando's open data portal comes with the following description:

This dataset comes from the Orlando Police Department records management system. It includes all Part 1 and Part 2 crimes as defined by the FBI's Uniform Crime Reporting standards. When multiple crimes are committed the highest level of crime is what is shown. The data includes only Open and Closed cases and does not include informational cases without arrests. This data excludes crimes where the victim or offender data is or could be legally protected.

This paragraph is followed by a long list of excluded crimes, including domestic violence, elderly abuse, and a list of sexual offenses, among others. So it's important to note that this data set says nothing about those types of crimes.

It's also important to note, going back to our discussion about the gap between data and reality in our chapter on epistemic errors, that we're not looking at actual crime, just reported crime. There's a difference. The site where I found the data also includes a disclaimer that “operations and policy regarding reporting might change,” so be careful about considering comparisons over time. In other words, a jump or a dip in one type of reported crime could be due to a change in the way police are doing their jobs, not necessarily due to a change in criminal activity itself. Not mentioning these caveats and disclaimers is misleading in and of itself. It can be inconvenient for us to do so because we might feel it will pull the rug out from under our own feet as we seek to make a powerful case to our audience. But it's just not ethical to omit these details once we know them.

1. Showing them a chart that's misleading

If we wanted to impress upon our audience that reported cases of narcotics are on the rise in Orlando, chances are that if we show them this 40-week timeline, we'd affect their understanding quite convincingly (Figure 7.4).

There's nothing factually incorrect about this chart at all. It's not even poorly designed. But it's terribly misleading. Why?

Because if we open up the time window on the horizontal axis and explore the trend of reported cases of narcotics covering the entire 8-year period, the data tells a very different story. The initial 40-week period is shown in the shaded gray region in Figure 7.5.

Now, this may be an innocent case of failing to examine the trend in broader context. Or it may be a case of outright deception by intentional cherry-picking. In either case, though, we have made a tremendous graphical gaffe by showing our audience something that left them with the exact wrong impression.

It's possible to play with the configurations of many different types of charts to mislead an audience. This is just one simple example. I'll refer you once again to Alberto Cairo's How Charts Lie, as well as an older book by Darrell Huff, How to Lie with Statistics.

The fact that it's possible to pull the wool over people's eyes in this way has caused many to be wary of statistics for a very long time. The following quote comes from a book called Chartography in Ten Lessons⁴ by Frank Julian Warne that was published in 1919, a full century prior to the year in which I am finishing writing this book:

To the average citizen statistics are as incomprehensible as a Chinese puzzle. To him they are a mental “Mystic Moorish Maze.” He looks upon columns of figures with suspicion because he cannot understand them. Perhaps he has so often been misled by the wrong use of statistics or by the use of incorrect statistics that he has become skeptical of them as representing reliable evidence as to facts and, like an automaton, he mechanically repeats “while figures may not lie, all liars, figure,” or the equally common libel, “there are three kinds of lies – lies, damn lies and statistics.”

Misleading people with charts injects some bad karma into the universe. We're still paying for the decisions of a few generations ago that led people into this exact pitfall. As a result, the collective human psyche is quite wary that data and charts are likely purveyors of trickery and falsehood, not truth.

2. Showing them a chart that's confusing

Slightly less egregious than the previous type of chart that misleads is the one that confuses an audience. The only reason this type of pitfall isn't as bad is because our audience doesn't walk away with the wrong idea. They walk away with no idea at all, just a bewildering feeling that they must've missed something.

There are really many more ways to confuse people with data than I can list or explain here. Many basic charts are confusing to people, let alone more complex ones such as a box-and-whisker plot. Does this mean we stop using them? No, but we may need to take a moment to orient our audience so that they understand what they're looking at.

But one of the most common ways to confuse someone with a chart is to include too much in the view. For example, if we wanted to focus our audience's attention on reported cases of shoplifting, and we showed them this timeline, we'd be right at the bottom of this pitfall (Figure 7.6).

Do you see what happens when you look at this chart? If you're like me, you make an honest and even an earnest attempt to verify that the presenter or the writer of the accompanying text is telling you something accurate. You struggle to find what you're looking for, and you start to get confused and then frustrated. The lines and the colors and the way they cross and overlap just make your brain scream when it can't find the information it's looking for. And then you give up.

Why do we insist on showing so much data to our audience all the time? It's like there's this irresistible temptation to include everything in the view, as if we'll get extra credit for adding all that data we've played with. Are we trying to impress them? We're not, we're just confusing them. Strip away all the extraneous stuff, or at least let it fade into the background.

You might hear this type of chart referred to as a “spaghetti chart” for obvious reasons. Notice a few things about it, if you don't mind. First, notice that “Shoplifting” has been given a light beige color. This was assigned as a default from the Tableau Desktop product I used to create it. Now, there's nothing inherently wrong with beige, but it sure is hard to pick the beige line out of the jumbled lines. If that happens to be the default assignment for the exact line or mark to which we want to draw attention, we will want to change it to something more noticeable.

Next, consider how many different lines there are. If you count the items in the legend, you'll see that there are 24 different lines. But there are only 20 different colors in the default color palette that the software applied to the offense type variable. So when it gets to the 21st item in the alphabetically ordered list, the software applies the same color that it applied to the first item. The 22nd item gets the same color as item number 2, and so on. Accepting defaults like that can be a rookie mistake, to be sure, but I've made that mistake many times, and many times well after I've been able to call myself a rookie.

What's the effect of this color confounding (which we'll consider more in the next chapter)? Take a look at the top line. It's light blue. Find light blue in the legend. To what offense type does it correspond? Does it correspond to “All other larceny” or “Theft from building”? We can't tell just by looking at the static version. We'd need to hover over an interactive version, or click on the legend to see that it's the “All other larceny” category. If a chart requires interaction to answer an important question, but it's presented in static form, then that's a surefire way to confuse people.

Going back to our original goal of bringing awareness to the shoplifting data, we can change the color for “Shoplifting” from light beige to something bolder, a color that's uniquely assigned to that value. Then, since our point is about the increase in rank, we'll leave the other lines in the view instead of removing them altogether, but we'll give them a lighter appearance or apply transparency to them to make the line series we want our audience to notice stand out (Figure 7.7).

Taking the time to make these minor but important tweaks to our charts will go a long way to ensuring our audience isn't staring at the screen or the page with that furrowed brow and that feeling of being completely lost. We don't want that.

3. Showing them a chart that doesn't convey the insight we want to impart

Let's say you and I are trying to educate a group of citizens about the state of reported crimes in Orlando, and we have a slide in which we'd like to make it immediately clear that three categories – theft, burglary, and assault – together have accounted for three out of every four reported crimes. Which of the following four alternatives in Figure 7.8 would you choose to make this point to your audience?

I'd argue that the pie chart and the treemap both make this point fairly well, and that the bar chart and the packed bubble chart don't. The reason is that the pie chart and the treemap each group all of the marks – slices in the case of the pie chart and rectangles in the case of the treemap – into a single, cohesive unit. In the case of the pie chart, the three slices we're asking our audience to pay attention to stop at almost exactly 9 o'clock, or 75% of a whole circle.

I'd argue that using 12 distinct color hues to make a point like this is a bit distracting, and that a simplified version of the color palette would make the point even easier for our audience to observe (Figure 7.9).

Notice how the simplified color scheme doesn't really make the share figure any clearer in the case of the bar chart and the packed bubble charts. That's because each mark in these two charts – rectangles in the case of the bar chart and circles in the case of the packed bubble chart – are separated in a way that doesn't give the notion of a cohesive single unit like the others do.

So we have two chart types that make the point we're trying to make abundantly clear and immediately noticeable. But we should ask ourselves another very important question: Is it actually fair and accurate to show this group of reported crimes as a single, whole unit? Think back to the caveats that were listed about this data: it only includes Part 1 and Part 2 crimes based on the FBI's standards. It only includes cases that were both opened and closed. In the case of multiple crimes, it only includes the highest level. And it doesn't include crimes where the victim or offender's identity could be legally protected.

That's a lot of caveats, isn't it? Does this data set represent a single anything, then? Perhaps not. If not, maybe it would be better to use a chart type, like a bar chart, that doesn't impart the notion of part-to-whole. If we do decide to show our audience a part-to-whole chart type like a pie chart or a treemap, and certain substantial elements aren't included in the data for whatever reason, we'll want to make that very clear to our audience. If we don't, we can be pretty sure that we'll be misleading them.

5. Showing them a chart that misses the real point

In describing this pitfall so far, we have concerned ourselves with individual charts, and whether they convey our message well to our audience and provide them with a general awareness that sufficiently matches reality. We have considered ways to create charts that introduce flaws that mislead, confuse, or provide inadequate visual corroboration for the point we're trying to make. We can classify these blunders as “sins of commission” – that is, they all involve an action that produces the problem.

But there's another way a chart can fail to convey our message. It can miss the point. Like failing to add an exclamation mark to a crucial sentence, or like criticizing the crew of the Titanic for their arrangement of the deck chairs, we can leave out something even more important and thereby commit a “sin of omission.”

For example, if we wanted to impress upon our audience that theft is the most frequently reported category of Part 1 and Part 2 crimes in Orlando, we could show them the pie chart or treemap in Figure 7.12 to drive home the point that theft accounted for almost half of all such cases between 2010 and 2017.

And if we stopped there, we'd have missed the point. Why? Because if we look at the way the number of reported cases of theft in Orlando has changed on a monthly basis over this time, we'd see that it's growing in overall share (Figure 7.13).

In fact, if we look at the mix of reported Part 1 and Part 2 crimes in Orlando for 2017 alone, we see that theft accounted for just over 55% of such crimes (Figure 7.14).

By comparison, theft accounted for only 45% in 2010 (Figure 7.15).

The bottom line is that we didn't make the point as strongly as we could have. Our original chart selection failed to convey the fact that theft has significantly increased in share over the time period we were showing and is now much higher than it once was.

When we showed the original chart covering 2010 through 2017, did we give our audience a general awareness of reality? Yes, but we didn't make them aware of a fact that's perhaps even more important. We picked the right chart type (assuming we believe we're dealing with a reasonable “whole”), we chose color in such a way as to draw attention to our main point and category of emphasis, and we even added labels for added precision. And we did so with great courage, feeling confident that our pie chart was good enough in spite of the many pie-chart-hating hecklers we knew would throw tomatoes.

But we sold ourselves short by omitting a critical fact.

Data Visualization for Open Exploration

Many times when we create charts, graphs, maps, and dashboards, we do so for our own understanding rather than to present to an audience. We're not in “data storytelling mode” quite yet, we're still in “data story finding mode.” That's okay, and there's a time for this critical step in the process. It's actually a very enjoyable step when you enter a state of playful flow with a data set or even multiple data sets. You're deep in the data, finding out interesting things and coming up with brand new questions you didn't know you had, just like the epigraph of this chapter indicates is possible.

I love the way EDA – Exploratory Data Analysis – embraces the messiness and fluid nature of this process. The way we explore data today, we often aren't constrained by rigid hypothesis testing or statistical rigor that can slow down the process to a crawl.

But we need to be careful with this rapid pace of exploration, too. Modern business intelligence and analytics tools allow us to do so much with data so quickly that it can be easy to fall into a pitfall by creating a chart that misleads us in the early stages of the process.

Like a teenager scrolling through an Instagram feed at lightning speed, we fly through a series of charts, but we never actually stop to pay close, diligent attention to any one view. We never actually spend quality time with the data; we just explore in such a rush and then publish or present without ever having slowed down to really see things with clarity and focus.

For example, let's think about that rising trend of reported thefts in Orlando. It was really easy to drag a trendline on top of the line chart and see the line sloping upward and take away from a step that took all of 10 seconds that theft is getting higher and higher each month that goes by. After all, the line is angling upward, right?

But if we consider an individuals control chart⁵ (Figure 7.16), which is designed to help us understand whether changes in a time series can be interpreted as signals or mere noise, then we see a slightly different story.

Yes, there were months in 2010 and 2011 that were lower than we would expect (“outliers” either above the upper control limit – UCL, or below the lower control limit – LCL), and there was even a rising trend in 2013 (6 points or more all increasing or decreasing) and a shift to end 2014 and begin 2015 (9 points or more all on one side of the average line). But since January 2015, the number of reported cases of theft in Orlando hasn't see any statistically significant changes at all. That's 35 straight months of noise. Would a core message that theft is rising and rising every month really be warranted by the data?

If we had just rushed on to the next chart without stopping to look more closely at this one finding, we might have missed the deeper understanding we gained by slowing down and analyzing more deeply.

Trade-Offs Abound

What seems clear, then, is that if we want to optimize using all of these variables (and likely others) for our particular scenario and audience, then we'll need to do a lot of work, and it will take a lot of time. If the audience is narrowly defined (say, for example, the board of directors of a specific nonprofit organization), then we simply can't test all of the variables (such as behavior – what will they do?) ahead of time. We have to forge ahead with imperfect information, and use something called bounded rationality – the idea that decision making involves inherent limitations in our knowledge, and we'll have to pick something that is “good enough.”

And if we get the data at 11:30 a.m. and the meeting is at 3 p.m. on the same day? Running a battery of tests often just isn't practical.

But what if we feel that optimization is critical in a particular case? We can start by simplifying things for ourselves, focusing on just one or two input variables, making some key assumptions about who our audience will be, what their state of mind will be when we present to them, and how their reactions will be similar to or different from the reactions of a test audience. We reduce the degrees of freedom and optimize a much simpler equation. I'm all for knowing which chart types are more comprehensible than others. In a pinch, this is really good information to have at our disposal.

There Is Room for Both Approaches

Simon noted in his Nobel laureate speech that “decision makers can satisfice either by finding optimum solutions for a simplified world, or by finding satisfactory solutions for a more realistic world. Neither approach, in general, dominates the other, and both have continued to co-exist in the world of management science.”¹⁰

I believe both should co-exist in the world of data visualization, too. We'll all be better off if people continue to test and find optimum visualizations for simplified and controlled scenarios in the lab, and we'll be better off if people continue to forge ahead and create “good enough” visualizations in the real world, taking into account a broader set of criteria and embracing the unknowns and messy uncertainties of communicating with other thinking and feeling human minds.