Take a look at any dashboard, or at any other part of most BI applications, and you will, almost universally, see a predominance of red, green, or other "callout" colors that are used to draw a user's attention. We have all been preconditioned since our school years that Green=Good and Red=Bad. So there is no problem using these colors to indicate good/bad in dashboards, right? Right. And wrong.
We should begin our discussion with the purpose of using bright colors in dashboards in the first place. As many data visualization gurus have noted, people are perfectly capable of analyzing trends in charts that use only softer earth tones or even monochrome. For instance, take a look at the below chart:
This chart uses bright colors for no reason. Now look at the same chart in monochrome:
As you can see, there is no visible difference in the data clarity‒it is just as easy to understand the trend in this chart as in the bright version. The monochrome version is much easier on the eyes, however. And, even more importantly, the subconscious color message is neutral. As mentioned above, we have been conditioned to intuitively understand that red and green have meanings. On top of which, red and green are just the two most prominent examples; any bright color draws the eye. The result is that users often pay far more attention to the colors in charts than is appropriate for the data that the charts represent. In the above example, that could mean incorrectly inferring that just because the green bar is higher in 1998 that it is necessarily better. Suppose we add some context by now including a caption in the chart:
We can clearly see that, in this case, the fact that the green bar is higher in 1998 is actually bad news (certainly bad news for females, although crime is never good news, of course). Unfortunately, our brains do not work this way. We internalize the emotional message conveyed by colors on a much deeper level than the purely intellectual message conveyed by a legend/caption. We may think that we understand what this chart is conveying, but each time we catch a glimpse of it in the corner of our eye, the Green=Good message comes back.
The general importance of proper color use is excellently made
by data visualization guru Stephen Few, and is beyond the scope of this article. I hope we have established, though, that bright colors are not a prerequisite in and of themselves for a dashboard to be visually compelling. Please note that I am certainly not advocating the universal use of monochrome charts; colors are perfectly fine, as long as they remain subtle when a callout is not intended or needed. Which brings us to our next point: when are
Why We Use Dashboards
Think about the dashboard in your car. Or, rather, think about your car without a dashboard‒the car would continue to function normally, but you would just not have any feedback about certain things. Would you feel safe driving that car? I hope not! You would not know when the car was almost out of gas, would need to guess at your speed, and would have no indication if something had gone wrong with the engine of the vehicle. A dashboard in a business intelligence application should be designed with the same purpose as a car's dashboard: to allow the "driver" (application user) to garner meaningful information quickly in order for that driver to then be able to quickly take informed action.
The first principle of dashboarding, therefore, must be to only include charts and objects that provide meaningful information. In this context, meaningful information is limited to only that information that actually enables action by the user. Imagine if your car's dashboard displayed information about the current weather in Okayama, Japan, where the car was manufactured. Or displayed the total number of cars that you had passed since leaving the house that morning. Neither of these pieces of information is at all meaningful to your current drive. Now imagine that they are not only displayed, but displayed in bright red, while the gas gauge is displayed in black. Your eyes would constantly be drawn to irrelevant information when you first glance at the dashboard, and you would waste a frustrating amount of time and energy forcing them to instead focus on the relevant information. Eventually you would sell the car and would make sure that the next car you bought had a better dashboard. Translating this to business terms, that means that user adoption of BI apps drops when dashboards display data that users simply do not care about‒data that is not readily actionable. This is exponentially truer when that data is displayed in a distracting way, such as with bright colors, because then it is not only irrelevant, but actually distracts from information that is relevant. And one thing you can count on is that, just as drivers with bad dashboards will not give up driving, users with bad dashboards will not give up analyzing their data‒they will simply find a BI solution that better meets their needs.
To encourage users to use the applications that you create, let us now see how some critical "callout" design principles apply to real-world dashboards. The following dashboard was designed for use by senior management at banks:
The entire dashboard is rife with problems, but this article is only going to use it as an example of the "don'ts" of callout color and callout object usage.
Principle 1: Utility
As we discussed above, the first rule of dashboarding is that all parts of a dashboard must enable the user to take informed action. You should never sacrifice utility for the sake of beauty. In this case, the top 5 green "up" arrows draw the bank CEO's eye while not telling him anything meaningful. If the branches are doing well, what action should the CEO take? If everything is going smoothly and no course correction is needed, then why display the data in the first place? To argue that it can be used to reward branch managers is a bit of a stretch, as incentive compensation is typically handled at a much more detailed accounting level and not through such an obviously high-level dashboard. It frankly may not be appropriate to show top-5/bottom-5 information on this dashboard at all, but it is certainly not a good idea to use a bright green color to call out something that is good.
Principle 2: Honesty
If you look closely, you might be able to tell that the red and green arrows, in fact, indicate something that may not be true. The chart's label tells us that it lists the "Top 5 and Last 5 Branches By Performance." The chart does not indicate that a branch is performing better or worse than it was previously. A green "up" arrow, however, clearly makes the statement that the branches are not only the top 5, but are also performing better than they themselves have previously performed (they are "up"). The same self-comparison idea is true for the red "down" arrows. These are visual statements that are simply not supported by the data, are very misleading, and could potentially by dangerous. If a red callout absolutely must be used in this case, a simple red LED should replace the red "down" arrow. A red LED quickly tells users that something requires their attention and is "bad," but avoids quantifying the problem in a misleading way.
Principle 3: Consistency
A good rule of thumb is that a single color should always be used to mean the same thing (preferably throughout the entire application, but certainly within a single sheet). In our example dashboard, the "Outstanding Value" horizontal bar chart uses a red that appears to be virtually identical to the one used for the "down" arrows. Subconsciously, our brains will try to associate things that have the same color. In this case, the identical color usage appears to have been unintentional, as there is almost certainly no correlation between the two charts.
Tip: this powerful principle can be leveraged to your advantage, as well. For example, it can allow you to create a single legend for your entire application; users will become accustomed to the fact that a certain color always means the same thing in your applications. Not only is this a powerful visualization technique, but will save users the effort of frequently having to consult a legend.
Principle 4: Avoid the Casual Use of Red/Green
Along the same lines as Principle 3, it is important to understand the subconscious power of red and green, specifically. As mentioned in this article's introduction, we have been preconditioned to intuitively understand that green is good and red is bad. In the example dashboard, red has been used casually in the "Outstanding Value" horizontal bar, as if it was just another color in a general color palette. This practice can confuse your users, however, and should be avoided. This problem is particularly prevalent in organizations where the color red appears in the company logo. In an effort to paint the application with the corporate brush, the overambitious designer will often attempt to integrate red elements in dashboards. The result is usually an application that is glaringly bright and/or sends contradictory messages to users (e.g. sales are up, which is good news, but the sales bar chart is red, which means something is wrong).
Principle 5: Take All Users Into Account
have shown that up to 10% of men are red/green color-blind. If you are designing a dashboard for an organization that employs an equal amount of men and women, that means that an average of 5% of your users will not be able to distinguish green versus red. For this reason, it is a good idea to use different saturations or luminosities (the S and L of the HSL color system) when incorporating red and green into your dashboard. For instance, you might use pale green and dark red. This would make your dashboards easier for color-blind people to use, as even those with color-blindness can differentiate color saturations. As you can see, this principle was unfortunately not followed in the example dashboard‒the red and green arrows appear to be at approximately the same saturation and luminosity.
While using arrows that point in different directions might also mitigate the problem, Principle 2 dictates that arrows should not have been used in this dashboard in order to avoid issuing a misleading message. Always keep in mind that, in the event of a conflict, utility trumps decoration; it is never acceptable to use a symbol that has a specific meaning when you do not intend that meaning. Using green “up” arrows and red “down” arrows to further differentiate simple good/bad indicators is not a good practice; by contrast, using green squares and red circles is fine, since neither symbol has an inherent meaning and so does not represent any conflict of utility and beauty.
Tip: you can also use the saturation/luminosity technique to easily enable users to differentiate between degrees of good/bad; for instance, a bright red LED could indicate that a KPI is significantly worse than it should be, while a pale red LED could indicate that the KPI is only slightly negative.
Principle 6: Not All That Is Negative is Bad
While this principle is not demonstrated in our example dashboard, it is, nevertheless, very important. It is not uncommon to see the color red always used to indicate negative growth and the color green to indicate positive growth. However, take the following chart of product sales growth over time:
Unless this organization's strategy is to encourage their competitor's success, the chart uses red and green coloring incorrectly. In certain situations, such as a competitor's growth, a negative number is actually a positive for your business. Make sure that your good/bad color usage aligns accordingly. Along the same lines, consider using some sort of thresholds when creating green/red indicators. For instance, perhaps a decrease in sales of only 0.05% is not a cause for worry. According to Principle 1, therefore, a red callout should not be used in that case (since no course correction is needed).
This is by no means an exhaustive list of color-related best practices in BI and only briefly touches on the proper use of non-callout colors and objects. However, the 6 principles that are laid out in this article are universally applicable. If you apply them consistently, it will almost always result in better visualizations, and in dashboards that enable your users to gain insight from your applications like never before!