In this second installment of our blog series on best practices in project reporting, we’ll cover the importance of color, and how it can best be used in your project charts. Most of us are already using color in project reporting without much thought today, but it does make sense to step back and understand how color should be used and why.
Color, more so than any element of your project report, can be used in a number of powerful ways:
- Engage the audience: Your audience will more likely to pay attention to a colorful chart, especially if that chart is competing with other distractions (smartphone, chatter, etc.)
- Distinguish important elements: Our brains (by way of the eyes) are very good at detecting differences in color, which means that colors are a good way to call attention to different groups of data in your project report.
- Communicate psychologically: Different colors evoke different emotions and reactions. We’ll get into the science of color selection in a future post, but for now, it’s probably safe to assume that something painted bright red may have different implications than something painted cool blue.
Before we get into how color should be used, let’s take a look at an example of a project report without any color:
All in all, pretty boring. It doesn’t engage the audience, and you can’t really tell which elements of the chart are important. This is comparable to what you get out of the box in Microsoft Project and other PPM solutions, and is part of the reason for the negative sentiment around Gantt charts in general.
A splash of color would certainly help things along, but there is a right way and a wrong way to do it. When deciding how to color-code your project reports, there are three key rules to keep in mind:
- Selecting which dimension of your project is best for color-coding
- Ensuring that colors are easily distinguishable
- Maintaining consistency
Selecting a Dimension
If you want the colors in your project reports to be meaningful, you need to assign them in a meaningful way. This means that you need to select a dimension of your project to drive the color-coding. Common dimensions include status, phase, and resources, among others.
When selecting a dimension, you want to make sure that you do so in a way that doesn’t create too many colors on the page. For example, choosing to assign a different color for each individual task is a bad idea because your chart will end up with too many colors, which makes it very hard to distinguish what the colors actually mean:
As a rule of thumb, try to select a dimension of your project that will result in 5-7 distinct colors. This is a good rule for two reasons. First, cognitive psychology tells us that our brains can remember about seven items at once (plus or minus two). If you go too far above that, it’s not going to stick in people’s heads. Second, it’s easy to think of seven distinct colors (red, yellow, blue, green, orange, purple, black). Once you get beyond that, you get into weird shades (sky blue, teal, etc.) that are more difficult to tell apart.
In the example, below, we’ve color-coded our chart based on status. It’s much easier to get information from three colors than the 21 different colors above:
Using Distinguishable Colors
The second item to consider is whether or not the colors on your chart are easily distinguishable. Have you ever wondered why traffic signals use bright, vivid colors instead of pastels? The same holds true when you’re building a report or giving a presentation: the colors need to be easy to quickly tell apart.
Here is an example of the same status chart using pastel colors instead of the vivid colors from before. It’s much harder to read, because the colors are more difficult to distinguish:
When selecting colors from a palette, make sure that there is enough variance between the different colors you select so that your audience can easily spot one from another. You can do this by selecting colors that are more saturated, or simply by avoiding too many colors from the same family.
Both of the rules we’ve discussed so far are actually pretty easy to remember if you think about the whiteboard markers that are in your office or your conference room:
Unlike crayons, whiteboard markers don’t come in 64 different colors, and each color is very easy to distinguish from the next. The dry erase guys figured this out a long time ago (despite sniffing all those fumes), and it’s an easy principle to apply to project reporting.
The third rule is to make sure that you are using colors consistently across your different project reports and presentations. This is a pretty easy rule to follow, provided you build a good foundation with #1 and #2.
Your audience doesn’t want to have to learn a new color scheme each time they look at a different project report. So, if you decide to color code based on project status, stick with it, and make sure that the colors you use in one report correspond to the next. After all, it’s confusing when high-risk items show up as red one week and green the next.
Of course, you’re not locked down to only using a single color convention. Sometimes you need to color code by status, and sometimes you need to color code by resources. Just make sure that if you do change conventions that you make it clear to your audience so they don’t spend a lot of time trying to figure out which way is up.
What other best practices have you come up with when it comes to using color in your project reporting? We’d love to hear them. In the meantime, we’ll move onto our next topic in the series: swimlanes.