Blogs

Mark Miller

Great UI: Clarity and Color on the Presentation Layer

Color consists of:

  • Hue Hue
  • Saturation Saturation
  • Lightness Lightness

Consider the images below:

     
On the left gaze attracts toward the deeply saturated hues, and the mind grapples with the hue variance and attempts to discern meaning (of which there is none).   On the right, with all shapes represented in the same hue, gaze attracts toward interesting details and the mind attempts to discern meaning from shape, of which there is a great deal.

From this, an important lesson:

Hue variance should justify itself.

Two screen shots from the iTunes installer: one real; one altered.

 
On the left you have an interesting variety of hues, with saturation and lightness apparently disconnected from information relevance.    On the right the same data is represented with only a single hue. Saturation and lightness levels are consistent with the information presented.

Which image would you rather see during an install?

So hue variance must be justified. Following this guideline over time, we eventually realize a second, important guideline:

Fewer hues is better.

Now let's move to an example that pretty much disregards that guideline. Here's a screen shot from an Excel spreadsheet we use to track refactorings shipped in Refactor! Pro (click to see the full-size image):

In this spreadsheet, each language supported has a dedicated color (e.g., C# is red, VB is green, C++ is orange, etc.). Also, at the far right of the spreadsheet we track the version where each refactoring was introduced, and also we also note whether that refactoring ships in CodeRush Xpress or Refactor! for Visual Basic. Here too color carries meaning, and is useful. If you're interested in refactorings that only support XAML, for example, you can scan your eyes down and look for a blue circle in the XAML column.

The column headers serve as a legend of sorts, connecting color to the data it represents:

We even follow this convention in descriptive text inside the spreadsheet, for example in this description for the Rename refactoring:

Speaking of Excel, the Excel application itself uses color in an interesting way. When editing formulas, Excel uses color to connect the cell reference in the formula to the cell on-screen. In the screen shot below, the cell reference "R[-4]C" is rendered in blue, and there is a corresponding blue box surrounding that cell:

On to a practical example. Let's say we have an application that presents sales data to managers, like this:

Managers using this application want to quickly see the best and worst members of the sales team.

So let's use red to indicate the lowest values, and green to indicate the highest values.

That's not too bad. Now at a glance we can see the best and worst performers for any quarter. And we've reached a third guideline:

We can enhance clarity with color.

Sometimes I hear developers say:

"You shouldn't use color at all to convey meaning, because a significant percentage of the population is color blind."

Is this a reasonable guideline to follow?

Let's find out.

First, a bit of background: Color blindness affects 8.6% of males and about 0.4% of females (or 4.5% of the entire population). Our eyes detect low-light variances with rod cells, and full spectrum bright-light variances with cone cells, of which there are three types: L-cones, M-cones, and S-cones. When there is a defect or absence in one of these groups of cones, color blindness occurs. Many of the color vision genes fall on the X chromosome, which is why color blindness occurs more frequently in men.

Here's the color vision breakdown for humans on this planet:

In addition to the percentages listed at the top, each color vision category in the figure above includes a list of six named colors, rendered as a person in that category would view them. Note that for the two most prevalent forms of color blindness (M-cone defect and L-cone defect), differentiating between red and green, as well as between blue and magenta, is challenging if not impossible.

Notice however that for all categories listed, differentiating between red and blue is relatively easy.

How does this impact our widget sales application? For someone with an M-cone defect, the data looks like this:

And we lose our at-a-glance ability to see the highs and lows. But what if we take the information learned above, and instead of using red and green, we differentiate with red and blue? Then to someone with normal vision, that change looks like this:

And to someone with an M-cone defect, the same data would look like this:

And so we are able to keep with the intent of using color to convey meaning, and do so in a way that works even with people who are color blind.

And we have a new, important lesson:

When conveying meaning with color, use reds and blues to differentiate, rather than reds and greens.

Speaking of conveying meaning with color, you might be wondering what Excel's cell-reference color-highlighting looks like to someone with an M-cone defect. It looks something like this:

As you can see, we get into trouble with Excel's choice of color for the first and third cells referenced in the formula. The blue and magenta both appear blue, and are nearly impossible to distinguish. Here are sections of the two views, enlarged:

Should Microsoft address this? Well, let's look at the impact. Editing formulas is something most Excel users do at some point with the product. So it's a highly visible feature of the product. Excel has over 450 million users, and that means over 20 million color blind Excel customers are impacted by this choice. Seems like the answer is a resounding Yes.

So how can the Excel team fix this? One option would be to slightly increase the lightness of the third color, magenta, so it appears as a lighter blue to someone with an M-cone defect, making it easier to distinguish from the first color. That simple change would look like this:

All this leads us to a final lesson about color:

When conveying meaning with color, differentiate by varying lightness in addition to hue.

So here are the guidelines for color, once again:

  • Justify hue variance.
  • Fewer hues is better.
  • We can enhance clarity with color.
  • Use reds and blues to convey meaning, rather than reds and greens.
  • Convey meaning by varying lightness in addition to hue.

Coming soon, we'll discuss clarity and noise. After that we'll dive into the second essential component of Great UI: efficiency.

Published Feb 26 2009, 02:37 PM by
Filed under:
Bookmark and Share

Comments

Brian Boatright

This is a great article and useful to just about everyone. Please keep them coming. Thanks Mark!

February 26, 2009 8:58 PM

Milkweed

Excellent!

The article would be even better if you could provide provide references for further reading. Thanks in advance,

February 26, 2009 9:18 PM

Kahn

I hope one day you write a book on UX and UI Design. I believe you are one of the best. Any books in particular you would recommend to read to get better at UI Design?

Thanks

February 27, 2009 1:04 AM

George Malekkos

Excellent article! Look forward to the next one.

February 27, 2009 2:17 AM

Antonio Vazquez

Excellent!

Really I will buy a book with all this information.

These things are the difference between "professional" high quality software and amateur.

When you see software made with all these rules, you feel "comfortable", and when don't you look the screen and you don't know why, but you don't feel that and the software looks worst.

For Kahn: I read a book about the design of Web pages from Jakob Nielsen "Designing Web Usability" where you will see a lot of ideas. This book explains not only the design, but how the user "thinks".

February 27, 2009 3:39 AM

Paul

One important thing to add to the color-blindness issue.  It isn't just a matter of usability, for a business it's a matter of legality and financial impact.  The American's with Disabilities Act can be applied quite broadly.

If an application uses color alone  to differentiate something critical to an employee's job, then a color-blind employee could be adversely impacted.  The ADA requires "reasonable accomodations" be made, but that term is interpreted by sometimes unreasonable courts.

The last thing an IS department wants is to be the cause of their business unit having to (under court order) hire a second person to tell an employee what color things are in the software.

February 27, 2009 7:29 AM

Dew Drop - February 27, 2009 | Alvin Ashcraft's Morning Dew

Pingback from  Dew Drop - February 27, 2009 | Alvin Ashcraft's Morning Dew

February 27, 2009 8:26 AM

Adam Leffert

Almost everyone quotes Nielsen as one of the top authorities on Web design.  I've found many of his ideas helpful.

Can anyone explain to me why his site looks so awful?

Adam

February 27, 2009 9:42 AM

Matt Ellis

Fascinating article.

I'm slightly colour blind. It was described to me as red-green deficiency; I don't know how that maps to your chart. I'm a bit bemused at the idea of the images of the 6 colour names - what should they look like to someone who's colour blind? I can see all of them as very different, and the first is vibrant and easily distinguished.

Anyway, not what I wanted to say.

I liked the point about changing the red+green text to red+blue. It's interesting because you're concerned with how the colours are being perceived, but you're not looking the black. I have no problem distinguishing between the red and the green, but the red and the black is much harder.

It'd be nice to see how black factors into the points you were making.

But great post, really interesting.

Cheers

Matt

February 27, 2009 5:31 PM

Matthew K

Hey, doesn't that color vision breakdown assume that we're not colorblind? :)

February 27, 2009 6:37 PM

Alberto Cortes

Simply Excellent Article.

Thanks Mark.

February 28, 2009 7:10 PM

drew..

@Adam: how very very true. A quick peek at the first site returned by googling his name show what appears to be a first attempt using FrontPage.. I wouldn't waste much time there without prior knowledge of usefulness.

March 2, 2009 2:33 PM

Tarik Souirji

From a colorblind:

+1 for the red/black issue. When I was at school, we had those shiny whiteboards and to this day I still hate the fact that teachers always went for black and dark red when they wanted to draw those complex and important diagrams .... I just couldn't follow.

Color isn't enough for clarity, add lightness and shape (bold/italic/regular or dotted lines, square/circle/star/triangle).

Ever seen a colorblind playing pool??

- "What wasn't that a red one?"

° "no that was the brown one......"

- "What now, did I hit the brown one again??"

° "no, this time it was the green one ...."  

Loosing at a pool table isn't such an issue, but misinterpreting a financial chart or messing up an excel formula could be career threatening for your end-users.

Great series of articles.

Cheers -

March 3, 2009 10:32 AM

Mehul Harry (DevExpress)

Interesting article on Label placement in forms:

www.uxmatters.com/.../000107.php

March 4, 2009 6:51 PM

Jack Phillips

Believe it or not I work for a company that has at least 30% of the users that ARE colorblind! Unforntunately this includes the owner.

Red means nothing to most of them and forget about orange. Blues and greys are abou the only thing that I can use safely.

March 6, 2009 5:53 PM

Caleb Jenkins-1

I've finally got some time to read these post. Really like them - thanks Mark! Great UI reading ... and very well thought out.

March 21, 2009 1:56 AM

zero.five » Blog Archive » Colors in C# and VB.net and Color-Blind Friendly Software

Pingback from  zero.five  » Blog Archive   » Colors in C# and VB.net and Color-Blind Friendly Software

March 24, 2009 12:56 AM

Bevan Arps

An informative post, but I suggest some of your conclusions are incorrect.

I have a mild form of colour blindness - an insensitivity to red, that leaves reds appearing darker to me than to those with normal sight. In the colour vision breakdown, above, the demonstrations for the L-Cone and M-Cone defects look identical to me.

Yes, Blue and Red are visually distinct - that much is true.

What you've missed is that black and red are very hard to distinguish from each other. Red text on a black background (or the reverse) is nigh on impossible for me to read.

The problem is that any meaning highlighted solely with red text is lost for me, because I don't see the cells as any different.

The key is that you are using 3 colors to convey information: red for low, blue for high, and black for neither. All three need to be visually distinct.

This isn't an argument to avoid the use of color in UI, far from it - intelligent use of color in the UI increases information bandwidth in useful ways. Just don't rely on colour alone.

April 3, 2009 6:57 PM

Nick

Great article, Mr. Millah.

I thought I was colour blind before I read this, I guess I'm not that bad.

My problem? Red from black. While I do need to look closely to tell the blue and magenta apart, and it's way easier with the lightness adjustment, I'd be a late arrival to Jane's firing squad.

It took me some deep zooming to finally come to the conclusion that the fourth cell in the formula was black.

Off now to google if my problem involves rods and not cones..

September 6, 2009 11:54 AM

David Compton

Hey Mark did you ever get around to writing any more posts in this series.  I've just come across them today and found them very useful.

David

December 3, 2009 8:53 PM

Hudson and accessibility : don’t use green ball plugin « Java Thoughts

Pingback from  Hudson and accessibility : don’t use green ball plugin « Java Thoughts

December 4, 2009 4:28 PM

Mark Miller

Hi David,

No new posts in this series yet. Possibly in early 2010.

December 4, 2009 5:23 PM

About Mark Miller (DevExpress)

Mark Miller is a C# MVP with strong expertise in decoupled design, plug-in architectures, and great UI. Mark is Chief Architect of the IDE Tools division at Developer Express, and is the visionary force behind productivity tools like CodeRush and Refactor!, as well as the DXCore extensibility layer for Visual Studio. Mark is a popular speaker at conferences around the world and has been writing software for over two decades.
LIVE CHAT

Chat is one of the many ways you can contact members of the DevExpress Team.
We are available Monday-Friday between 7:30am and 4:30pm Pacific Time.

If you need additional product information, write to us at info@devexpress.com or call us at +1 (818) 844-3383

FOLLOW US

DevExpress engineers feature-complete Presentation Controls, IDE Productivity Tools, Business Application Frameworks, and Reporting Systems for Visual Studio, along with high-performance HTML JS Mobile Frameworks for developers targeting iOS, Android and Windows Phone. Whether using WPF, Silverlight, ASP.NET, WinForms, HTML5 or Windows 8, DevExpress tools help you build and deliver your best in the shortest time possible.

Copyright © 1998-2014 Developer Express Inc.
All trademarks or registered trademarks are property of their respective owners