Effectively using color to represent data.

A continuation of Putting the G in your GUI.

The primary reason for including colors in your UI can be understood by the logical synthesis of two basic principles:

• Colors are pretty.
• Users like pretty.

But what about the usability side of UX? Can colors be used for more than aesthetic reasons? Do they improve user performance of a task? Well, usually not. Various studies going back to old character-cell displays when color was first introduced generally fail to find an advantage for color. This led me in the days of DOS to purchase a monochrome amber monitor for my first computer, while my coworkers were investing in more expensive sixteen-color VGA units. Yeah, nice blue background you got there for Wordperfect, dude, but does underlined text actually appear underlined? Or does bold look bold. Hmph!

It’s pretty much the same for the web. Despite an increase in the number of colors we can display by several orders of magnitude, the way colors are typically used does little to improve performance. Coloring your menu items, headers, pictures, and different sections of content generally isn’t going to make content easier to find and see than a black-and-white version of the same. Usually you can group, emphasize, and distinguish content just as well with spacing, lines, and font size, style, and weight as with color. You need to color your links so users will recognize them as links, of course, but only because we’ve so successfully set that expectation. If the web from the start used a non-hue convention to distinguish links (like an icon or a gray background), I expect performance would be the same, maybe even better. Users often think that color improves their performance, but it’s all in their mind, you know -a halo effect of the more pleasant experience that color brings. For most cases, designers are concerned with not degrading user performance when introducing color for aesthetic reasons, rather than enhancing performance with color.

Colors Use that Improves Performance

However, there is one area where color has the potential of enhancing user performance, and that’s the use of color coding, where color is a graphic dimension used to represent an attribute value of a data object. By color, in this case, I specifically mean hue, but saturation and brightness are also typically varied in color codes, especially the latter for accessibility reasons. Color makes things look distinct. Of all the graphic dimensions, only position and maybe shape rival color in making things look different for most practical purposes. This makes color coding helpful for the following user tasks, ranked in order of suitability:

• Pattern recognition.
• Visual search.
• Value Identification.

Often the same display needs to support all three tasks.

To see how color can help with each of these tasks, consider the following symbol set for the icons or object controls used to display fanciful naval assets on a tactical display. We’re using shape coding to represent the class of the object (type of naval asset, in this case), which is often the most sensible thing to do.

Symbol	Class	Abbrev.
	Main Echelon for Naval Engagement	MENE
	Ballistic Operations Naval Combat Regiment	BONCR
	Tactical Unit for Reconnaissance and Combat	TURC
	Combat Long-range Operations Unit – Naval	CLOUN
	Ground-support Levitating Unmanned Vehicle	GLUV
	Submarine	SUB

With shape used to represent the class of the asset, we’ll use color to represent it’s current function:

Color	Name	Function
	Red	Offense
	White	Force Protection
	Magenta	Intelligence
	Blue	Command and Control
	Yellow	Special Forces
	Green	Logistics

The example display below lists the assets, with the icons using both the shape and color codes. The table is sorted by class of asset, and then by identifier.

Pattern Recognition

Pattern recognition is the spontaneous perception of relations between attributes. In the window above, for example, a casual scan of the table reveals that command and control is primarily the responsibility of the MENEs and vice versa. A solid block of blue icons in the “MENE” part of the table, and a lack of blue elsewhere makes this apparent. Color creates a strong sense of grouping which emphasizes such patterns more than other graphic attributes. We could have tried representing the assets’ functions with a different graphic attribute than color. For accessibility reasons, the asset functions are redundantly represented by the shape of the outline of each icon, but this just isn’t as good as color. It’s unlikely the pattern would jump out as well if color wasn’t also used.

Of course, with a table layout, the user could sort the data on Function then scan the Class attribute and see that nearly all command and control is by MENEs, but the user has to think to do that. With color coding, the pattern is detectable without the user interactively looking for it. Besides, sometimes sorting isn’t an option, such as in this graphic layout below, a map showing the locations of the assets out at sea.

Here we see another pattern emerging: the command and control assets are all grouped in the central area surrounded by a ring of force protection units; offensive units tend to be more to the east. The separating effects of color are so strong, they in effect make overlapping data appear to have layers, with all things of the same color having their own layer. This is especially helpful when users need to attend to one pattern among overlapping patterns. Users can mentally filter out all but the color of interest to see the relations.

Color coding improves user performance on pattern recognition as long as meaningful patterns are associated with specific values coded by the colors. However, it can work against the users when the patterns depend on something else. For example it is probably less apparent that the BONCRs, whatever their function, are clustered in the upper right. The eye tends to see the different colored BONCRS as separate even though their icons are the same shape.

Sometimes the users can become so focused on the pattern among objects of one color that they fail to see its relation to objects of another color even when they’re looking right at it. They also may come to over-rely on color and fail to notice other information, such as text fields, that may qualify the interpretation of the color code. For example, a glance at the map may imply a pretty uniform distribution of logistics assets, but closer inspection of the lower left shows logistics being handled mostly by CLOUNs. I don’t mean to insult anyone, but those CLOUNs have no business doing logistics. Their transports are too small, for one thing.

The separation tendency of color limits how much you can use it. For pattern recognition purposes, you generally have to limit color coding to a single attribute. It’s probably not effective, for example, to color code the asset’s function in one part of the object image, and color code its readiness in another part. This can make the object no longer appear as a cohesive whole. Furthermore, users will tend to see the same colors for different attributes as representing the same thing, disrupting the users’ ability to see patterns in a single attribute.

Putting it together, and it’s apparent that with the great power of color comes great responsibility. You probably should only use color coding for an attribute whose values are reliably known and are highly task relevant.

Visual Search

Looking at the map above, find the asset responsible for Special Forces. You probably found it right away, likely faster than if I were to ask you to find the GLUV (there’s only one, not a pair), even though I made an effort to make each icon visually distinct. You’d also probably be faster and more accurate at counting the number of assets responsible for intelligence versus counting the number of TURCs.

Visual search tasks like looking for Special Forces and intelligence assets leverages the capacity of colors to visually separate objects, just like pattern recognition. However, visual search is a different task than pattern recognition. With pattern recognition, the user does a general scan and notices that certain objects in certain positions tend to have certain relative attribute values. In visual search, the user is looking for a specific attribute value.

Not appreciating the difference between pattern recognition and visual search can lead to a poor use of color, and that’s relying on changes in color to be meaningful to users. Users can easily scan a display and find a specific color, but unless they happen to be looking at just the right time in the right place, they will tend to miss something changing color. This is especially the case if the color the object assumes is not unique on the display -it’s not enough to constitute a major change in the general pattern. For example, if a couple BONCRs shift from a logistics function to offensive, don’t count on the user noticing right away. There’re lots of red offensive assets and a couple more is not going to pop out.

If a change in an attribute value requires prompt user response, then instead use some sort of repeating change or motion (time coding), like blinking or other animation. Humans are great at detecting cyclic variations in brightness in the peripheral vision, so such apparent motion will tend to get attention even at locations the user isn’t attending to. Human color discrimination, in contrast, is poor in the periphery, so hue changes alone are not so good even if they’re cycling. Of course, constant motion can draw too much attention, becoming a distraction, so you want to provide users with the ability to acknowledge and suppress the motion. At that point, the user knows the change has occurred, so there is no need for continued motion. Instead, however, the user may need to visually re-acquire the changed object, but now the task is visual search, which color coding is good for.

Value Identification

What is the function of the GLUV (in the center-right of the map above)? This is value identification, where the user is looking at an object image and must determine the value of an attribute, a task color can be good for because of the relatively wide number of colors we can recognize and distinguish. Text is generally the best for value identification -if users need to tell the function of the GLUV let them just read “Offense” from a Function text box. However, adding text attributes to your object image can be cluttering, and if you have graphic representations for other reasons, they may already be sufficient for value identification.

Among graphic dimensions, shape is generally best for identifying categorical data -users can recognize a remarkable number of different shapes, especially if the shapes have some sort of visual association with the concept they represent (e.g., the use of a stylized periscope to represent a submarine in the symbol set we’re using here). However, if you’re already using shape for one attribute (e.g., object class), color is a good choice for second attribute (e.g., function).

Absolute versus Relative Values

Consider the following graphic pane displaying seawater salinity represented with shades of blue and green, which is relevant for controlling the depth of submarines:

And consider these two questions:

• How is a salinity of 3.4 versus 3.8 distributed over the sea?
• How are high versus low salinity distributed over the sea?

These are both pattern-recognition tasks, but the first concerns the absolute values of the attribute represented by color, while the second concerns the relative values. Visual search likewise can be for absolute or relative values:

• Where is salinity of 3.2 found?
• Where are there “holes” in the salinity?

And value identification can also be absolute or relative:

• What is the salinity of the water where the submarine is now?
• Is the salinity more or less than that found immediately south of the submarine?

Graphic dimensions in general often are best for tasks concerning relative values. Humans can distinguish minute differences in size, orientation, shape, and color as long as the different representations are right next to each other. You can represent thousands of different values and your users will see the differences.

Graphic dimensions in general and color in particular are generally much less effective for tasks concerning absolute values. Position, size, and orientation may be used to read fairly precise absolute values for numeric or ordinal data, but only if you include an integrated reference (e.g., labeled gradation lines or a coordinate grid) so the task is really about relative comparisons. Otherwise you probably wouldn’t want to try to represent more than three or four values with these graphic dimensions if the user needs to identify the values reliably. You can have small, medium, and large, you can have horizontal, vertical, and diagonal, but any more is pushing it. Likewise with density coding. Crispness and the time dimensions? Probably best to keep each of them to binary attributes.

For reading absolute values without a reference, color is better than all other graphic dimensions except shape, but the number of color codes should still be far fewer than you can effectively have for reading relative values. A user’s ability to recognize a precise color when it appears in isolation is limited because the “same” color doesn’t always look the same.

• Despite standards, different displays (e.g., monitors, mobile devices, printers) render colors differently from one another due to differences in their design. What looks like amber on one display may look more like light brown on another. As your users move among displays, the potential to confuse colors grows. The extreme case is when they print your beautiful multi-colored data on a black-and-white printer.
• Even the same display will show different absolute colors under different conditions. Brightness settings, ambient light level and spectrum, display age, and viewing angle (for LCD displays) all affect the appearances of the colors. Is there a chance your users may be wearing sunglasses? What tint?
• Different users see colors differently. There is a fair minority of people with various forms of color perception deficiencies, which limits the differences they see among colors. A small minority of people are completely color blind, seeing only shades of brightness.
• Colors make colors look different. There are contrast effects where the color next to another changes how it looks. For example looking at the salinity display above, is not apparent that the “knoll” in salinity in the extreme upper left actually is the exact same salinity level as the “hole” in the lower right.

Put it together, and you should have no more than six color codes for reading absolute values.

Yes, so few colors limits the precision that of the display. Where once we represented the continuous range of salinity, now we’re only showing discrete ranges. However, your users are already limited in the precision they can identify absolute values. Showing greater precision is not going to change that.

Even then, you should generally include redundant non-color representations for accessibility and printing reasons. In the re-done salinity display above, for example, there is redundant shade coding in addition to hue, so that higher salinity levels appear brighter as well as greener. If your chosen colors represent some sort of scale, then the brightness values should be consistent with that scale. For example, if you have green-yellow-red as a scale of safety, make sure your green is lighter than your yellow (hint: try amber instead). Below I describe the formulas for calculating and comparing the brightness of colors.

Limiting the number of color codes does not eliminate the contrast effect. In the display above the upper left knoll looks lighter than the lower right hole. But with only five colors to choose from, users will likely recognize them as representing the same salinity. In an actual implementation, I might also show the salinity values of each region as text, perhaps on mouse-over to minimize clutter if other things are shown the on map.

You may be able to get away with more than six color codes if you provide a legend or key, like I’ve included in the salinity examples above. This is the color-equivalent of providing a reference marks for size, orientation, and position coding, changing an absolute-value task to a relative-value task. However, unlike a coordinate grid for position coding, the legend is not integrated with the colors on the display, so it doesn’t allow direct comparisons. For all graphic dimensions, the further the separation in time and space, the harder it is to make relative comparisons. A key won’t help color contrast issues, for example.

Selecting Your Color Codes

Having decided on the number of color codes to have, you now have to decide which colors to use. Typical digital displays can render over 16 million colors, but there are several considerations, some mutually contradictory, that constrain your choices.

Contrast among Codes

Obviously, your colors need to be distinguishable from each other. You want to avoid the difficulties MS Office 2007 presents its users with too little color difference between active and inactive title bars of the windows (click for full size).

I don’t know about you, but unless I have two windows side by side, I can’t tell at a glance if a window is active or not.

Fortunately, you can estimate the perceptual differences between any two colors by converting the colors’ RGB value to Luv coordinates, a color space where the Euclidean differences between colors is proportional to human perceived differences.

Follow these 5 easy steps, for which, as an example, we’ll perform on a lovely shade of carnation pink (#FF99CC, or 255, 153, 204):

1. Convert your RGB values into “rgb” values using the formula x = (X/255)^2.2

r =  (255/255)^2.2 = 1.0000

g = (153/255)^2.2 = 0.3250

b = (204/255)^2.2 = 0.6121

2. Matrix-multiply your rgb values by a constant matrix to convert them to XYZ color coordinates. As three formulas (rounded to four decimal places), it’s:

X = 0.4124*r + 0.3576*g + 0.1805*b

Y = 0.2126*r + 0.7151*g + 0.0721*b

Z = 0.0193*r + 0.1192*g + 0.9505*b

The Y dimension, incidentally, is the relative brightness value, which will come in handy later.

So carnation pink is:

X = 0.4124*1.000 + 0.3576*0.3250 + 0.1805*0.6055 = 0.6391

Y = 0.2126*1.000 + 0.7151*0.3250 + 0.0721*0.6055 = 0.4892

Z = 0.0193*1.000 + 0.1192*0.3250 + 0.9505*0.6055 =  0.6399

3. Calculate L, the gray-scale brightness level:

IF Y/0.9999 > 216/24389, L = (Y/0.9999)^(1/3) * 116 – 16

ELSE, L =24389*Y/0.9999/27

For carnation pink, 0.4892/0.9999 is more than 216/24389, so:

L = (0.4892/0.9999)^1/3 * 116 – 16 = 75.41

4. Calculate u’ and v’ for the two hue dimensions:

u’ = 4 * X / (X + 15*Y + 3*Z)

v’ = 9 * Y / (X  + 15*Y + 3*Z)

If X, Y, and Z are all 0, then set u’ and v’ to 0. For carnation pink:

u’ = 4 * 0.6391 / (0.6391 + 15 * 0.4892 + 3 * 0.6399) = 0.2583

v’ = 9 * 0.4892 / (0.6391 + 15 * 0.4892 + 3 * 0.6399) = 0.4449

5. Convert u’ and v’ into u and v coordinates.

u = 13 * L * (u’ – 0.1978)

v = 13 * L * (v’ – 0.4683)

For carnation pink:

u = 13 * 75.41 * (0.2583 – 0.1978) = 59.25

v = 13 * 75.41 * (0.4449 – 0.4683) = -22.97

So carnation pink (#FF99CC) has Luv coordinates of 75.41, 59.25, and -22.97 (within rounding error). That’s only an approximation, of course, assuming a “standard” luminous digital display. Individual displays vary a little from the standard, and these numbers mean nothing if you’re dealing with a printer. But what do you expect from such a simple calculation?

To know how well carnation pink contrasts with say, deep orchid (#9933CC, or 153, 51, 204), get the Luv coordinates for deep orchid (which are 43.36, 30.74, and -95.69) and calculate the three-dimensional distance separating them:

Color Difference = sqrt[ (L1 - L2)^2 + (u1- u2)^2 + (v1 - v2)^2 ]

Or:

Color Difference = sqrt[ (74.41 - 43.36)^2 + (59.25 - 30.74)^2 + (-22.97 - -95.69)^2 ] = 84.43

For comparison, the difference between black (#000000) and white (#FFFFFF) is 100, so you have quite good color contrast between carnation pink and deep orchid. You should also check the perceived brightness scale contrast, because in a lot of situations, brightness matters more in discriminating colors than hue (and I’m not just talking about users with color perception deficiencies). The two L values can be directly compared:

Brightness Difference = L1 – L2

Brightness Difference = 75.41 – 43.36 = 32.04

That’s barely adequate brightness contrast. However, if you want really bad, run the calculations on Office’s title bars, whose background colors average #DFE7EC and #DAECF8. The color difference is only 9 and brightness difference is essentially nil. No wonder I can’t recognize them.

Using the above process you can go through potential color candidates to select a set of codes that are reasonably distinct from each other. Do yourself a favor and put the formulas above in a spreadsheet to save yourself some time. Or download mine, putting in your RGB values in the framed shaded cells (no warranty expressed or implied, user assumes all risk, do not use while operating heavy machinery).

However, you don’t have to go through a whole lot of calculations to realize that high saturation colors are going to be more distinct from each other than low saturation colors, so maxing out at least one of the RGB values to FF is a good starting point for a color. Also keep in mind the following:

• Yellow and white are hard to discriminate since the human eye is maximally sensitive to yellow light (they have L’s 91 and 100 respectively), especially in low-contrast reading conditions (e.g., using a mobile device in sunlight). Avoid having both pure yellow and white as codes. Instead, you can make your white a pale blue, or make your yellow more of an orange or amber (like I did to code Special Forces), which will still contrast well with red, if you have that too.
• Very pale blue and white are also hard to tell apart, so avoid having them both too.
• Pure green (#00FF00) and pure cyan (#00FFFF) is another pair than can be easily confused at a glance. Give them a little extra space apart (e.g., #00FF00 and #00A0FF).
• Brown and orange also don’t play well with each other on the same digital display. You may want to use lighter shades of brown for good contrast on a dark background, but tan is just low-saturation orange; they have the same hue and brightness, making them much alike. If you have lots of tan objects on your display, orange is not a good choice of indicating an alarm state.

Background Contrast

Of course you need your color-coded symbols or icons to stand out against your background so your users can see and read them. Luv coordinates can also be used to determine foreground-background contrast, but brightness contrast (as represented by L or Y) is more important for foreground/background distinction. Thus, you generally want to go with pure white (#FFFFFF) or pure black (#000000) for a background to have maximum contrast with whatever colors you have for your symbols in the foreground.

As comparing L values will show you, if you’re using high-saturation colors to make them maximally distinguishable from each other, you’re usually going to get more contrast with a black background than a white one. However, white backgrounds can hide glare better and dark text on large white backgrounds is usually easier to read than light text on large black backgrounds, so if you’re displaying a lot of text in addition to symbols, you may want to work with a white background. Trying to compromise and use a medium gray background is not going to work.

L and Luv comparisons will also show you that some of your colors stand out more than others against a given background. That can be a good thing if the colors that stand out best are the more important ones to see. If not, then consider adjusting your color values so this is the case. For example, red contrasts relatively poorly against a black background. For coding alert states, you might want to go with orange. If you must use red, maybe you should use a white background, or you could outline the alert symbol in white, or use a red-and-white pattern to make it contrast more against a black background.

If you want to color code the background in addition to objects in the foreground, you’ve got a real challenge. Now the contrast of your foreground objects is going to depend on the background they happen to be on. Now you need background colors that are distinguishable from each other but still contrast well enough with all your foreground colors. Good luck with that. It’s pretty much impossible to get high contrast among a large range (over 3) of foreground colors, a large range of background colors, and between each foreground and background color. You must prioritize your contrasts:

• Most importantly, have good brightness contrast between each foreground/background pair of colors.
• Secondly achieve good color contrast among your foreground colors.
• Lastly maximize the color contrasts of your backgrounds.

The brightness contrast ratio for all possible foreground/background combinations should be at least 3.0. We use Y to calculate the ratio:

Brightness Ratio = (Y1 + 0.05) / (Y2 + 0.05)

Where Y1 is the larger Y of the two colors you’re comparing.

Background color contrast has lower priority than foregrounds because background codes tend to occupy relatively large areas on the screen, while foreground objects tend to be relatively small symbols or icons. Users can recognize and see differences in colors and brightness better when they occupy large areas. Save your vivid high-saturation colors for foreground objects. Use duller or paler colors for the background. This will not only optimize your user’s performance, it will also be aesthetically easier on the users’ eyes. Big areas of vivid colors will just drive them bonkers. If you need reference marks or other details in the background (e.g., graticule, borders), try to keep them to shades of gray so they won’t complicate the perception of the colored objects on top.

If you’re still having trouble getting good foreground-background contrast for all your color codes, try outlining your foreground objects with a high contrast color like white or black regardless of their background. That’ll help. In the example below that combines color codes for salinity with those for asset functions, I went a step further and surrounded the symbols with a small area of black.

Color Consistency

Your color codes need to be internally consistent throughout your product, of course. That includes using the same mapping of colors to values between sessions -don’t re-scale the color codes because the current range of values has changed. You also want your colors to be consistent with your user’s stereotypes from prior experiences. This includes the colors used in similar products (e.g., if users are used to regarding gray to mean “disabled,” they may assume the same applies to your icons), and more general cultural meanings associated with various colors. Most people in western civilization associate blue with cold or water. Red means fire, stop, or danger. Be careful who you call dangerous. At the very least, you want to be sure your colors don’t strongly contradict user expectations. If Offense is your most “dangerous” function, then make it red. Red is probably not a good choice for Logistics. Your sea is better off blue than brown, although you could get away with a sea of green as long as you’re not also trying to represent botanically lush terrestrial regions.

Consistency with user color expectations is complicated by the fact that different users have different stereotypes depending on their experience. Different cultures, subcultures within a culture, and eras within a culture will have different meanings for different colors. Color associations may vary by occupation, subject domain, or user role. For example, lay people would likely associate darker shades of blue with deeper water than lighter shades. However, for sailors familiar with traditional nautical charts, the opposite is true -white represents the deepest water.

Color Arbitrariness

Except for some stereotypes, color codes are arbitrary, and learning color codes can constitute a substantial memory burden (which is another reason to have only a few color codes). This is especially the case for color coding numerical and ordinal data. Other than ranking green – yellow/orange – red as an ordinal scale of threat, people don’t have a natural ranking for colors. When orders are imposed on colors, they are not consistent across domains. Electrical engineers use a different order than karate dojos, for example. To someone at Microsoft, gray suggests greater risk than blue, but I don’t know about anyone else.

However, this lack of consistent ranking only applies if you attempt to use nearly the entire spectrum. If you keep your color codes to a blend between two or three adjacent primary and secondary colors on the spectrum, people will see an order to it (although they don’t necessarily know which end is the “high” end). You can use Luv coordinates to make sure your colors are appropriately spaced on the scale they represent.

This is what I did for representing salinity, blending it from blue to green. Going through three adjacent colors (e.g., yellow-green-blue) is suitable when the middle of the scale represents a neutral or zero value (rather than simply “medium”), and also makes for more color contrast among the codes.

Of course, limiting your colors to a segment of the spectrum mean less color contrast among the codes than using the whole spectrum. However, if you also include changes in brightness like I have done to make it easier for your users, it may be adequate for background color coding, once again relying on the large areas the colors occupy. For foreground objects, you may want to use a different graphic dimension to represent ordinal and numeric data.

Accessibility

The best way to provide accessibility to users with color perception deficiencies is through some redundant representation in addition to hue. This includes:

• Ensuring your color choices are also well separated in brightness (L), while still all contrasting well with the background.
• Additional graphic codes like shape or size, such as I’ve done with the shape of the symbol outlines.
• Text representations of the attributes.

Of course, presumably you chose color to represent an attribute precisely because of the unique advantages that color provides (e.g., for pattern recognition).

Thus, users who have to rely on the redundant representations will be at a disadvantage no matter what. For example, the brightness difference of the color codes I’ve chosen for these maps is as low as 6 -that’s a too small of a difference to see. Furthermore, the brightness differences may imply a ranking that does not accurately characterize the attribute values. There’s not much you can do about this if you’re using a large number of color codes.

However, if you have only a few color codes (say, three), it’s possible to select colors (and levels of brightness) that ameliorate the situation for most users with color perception deficiencies. There are various tools on-line for testing your colors. A good place to start with the colors themselves is to stick to yellows and blues, since by far the more common form of deficiency concerns red-versus-green discriminations.

For example, eye-tracking heat maps should go blue-green (or gray)-yellow, rather than the green-yellow-red I usually see. For the most common form of color deficiency, the latter makes the two extreme values hardest to discriminate, precisely the opposite of what you want. The former preserves the “heat” metaphor (in Western cultural stereotypes, blue is cold, yellow is hot) and redundant brightness coding is relatively easy (of all the primary and secondary colors, high saturation blue has the lowest L value while high saturation yellow has the highest).

If you must use green and red, try the traffic-light trick and mix some blue with green and some green with red like I’ve done with the symbols in this set. This will make greens looks bluish and reds look brownish to those with red-green perception deficiencies. If you must use green-yellow-red (e.g., for ranking danger levels), use a pale bluish green and a darker red. This will appear as like blue-yellow-black to those who can’t discriminate greens and reds, which is still reasonably close to our cultural stereotyped associations between color and danger. It also can provide redundant light-medium-dark brightness coding.

Color Names

You want high-saturation colors for maximum contrast, and people will generally agree on the names for high-saturation red, yellow, green, and blue. However, other high saturation colors, such as magenta and cyan, have no widely accepted names. Many people don’t know what “cyan” and “magenta” mean. Some might call the former “aqua” while others call it “light blue,” for example. The latter may be “hot pink,” “fuchsia,” or “bright purple.” If you are going to use these colors -or any hues other than red, yellow, green, and blue, be prepared for possible confusion in written or verbal communication (e.g., with tech support). Yet another reason to limit your number of color codes.

Focal Accommodation

Due to the physical optical effects of lenses, including the ones in our eyes, different light frequencies require different degrees of focus. To focus on blue objects, for example, the lens of your eyes need to focus “farther” than to focus on red objects. This means to switch from looking at red objects to blue objects, users have to refocus their eyes, which can be tiring. You should avoid color sets that results in a lot of high-saturation red and blue objects if the task requires the user to shift focus repeatedly from one to the other.

Blue is hard to focus in general because of its short wave length, a phenomenon that grows more acute as a user ages. High saturation blue (#0000FF) should be avoided for anything that requires detailed study, such as text or subtly varying symbols or icons. Make it a darker or lighter blue (e.g., mix in some green) to avoid problems with this. The default color for unvisited links? Not really a good choice.

On the other hand, the difference in focus levels of different colors could be an phenomenon to exploit. Blue objects tend to appear farther away than red objects, an illusion called “chromostereopsis.” Stare closely at the symbols in the map below, and subs will appear “deeper” than the GLUV.

Well, sometimes it works.

This may help users visually filter out blue objects and focus only on red objects or vice versa. It could also be used to suggest different physical levels. Used to be they’d color code elevation on maps, with the seas being conveniently blue, and therefore at the bottom, while the mountains were reddish, appearing on top. It didn’t work out too well because it also meant sea-level deserts, like on the Arabian peninsula, appeared a rich green, suggesting heavy vegetation. Also, chromostereopsis is only a strong effect with very high saturation colors. However, it might be worth trying to use chromostereopsis in certain special-purpose applications. Maybe submerged assets like submarines should be blue while flying assets like GLUVs should be red, for example. More broadly, mixing a little blue in your background (e.g., using a midnight blue or very pale blue) may subtly help your foreground objects appear more “on top” of it.

So Many Colors…

…But so many constraints and considerations. It’s difficult to come up with a color set that even minimally satisfy them all. It easy to just throw up one’s hands and let the users choose the colors they want, but that rarely works out. If you as a usability professional can’t figure out how to balance all these constraints, what chance does a layperson have? If you see a need to let users choose their colors, provide a limited palette for limited purposes  (e.g., to pick the color to represent oneself). You can also provide a global color-contrast setting that adjusts brightness and color contrasts (consistent with Luv calculations) while keeping the hues fixed. Users can then adjust the colors to their liking for their current displays, viewing conditions, and visual abilities.

The effects of combinations of colors is not easily predictable, so once you have selected your colors for both foreground and background, you should test them as a complete system on your users, checking that they all work well together.

Summary Checklist

Problem: Using color codes.

Potential Solution:

• Use color codes to aid pattern recognition, visual search, and possibly value identification.
• Reserve color coding for attributes whose values are highly task relevant and reliably known.
• Do not rely on color changes to capture user’s attention.
• Limit the number of codes to 6 if absolute values must be identified.
• Use Luv coordinates to achieve distinct colors and good foreground-background contrast.
• High-saturation colors will be most distinct from each other.
• Foreground and background should have a brightness contrast of at least 3.0.
• Color codes for large background areas may be closer to each other than color codes for small foreground objects.
• Use colors consistently within your app and with user expectations and experiences.
• Remember that color codes can be arbitrary and therefore hard to remember.
• Consider using part of the spectrum for representing numeric or ordinal data.
• Provide redundant representations of the data for accessibility.
• Favor blue and yellows for maximum accessibility.
• Consider colors that are easily named.
• Avoid having high saturation blue and red objects used in the same task.
• Avoid high-saturation blue for text or fine detail.
• Limit user ability to customize color codes.