Designing the User Experience at Autodesk

Designing with the Color blind in Mind - Part 2

Tips for making color more accessible

by Mark Jamieson

Part 1 of this series provides information about the physiology of color blindness, and lists examples of situations that are challenging for color-blind people.

Part 2 provides tips to prevent color design oversights and help reduce accessibility barriers for color blind people.

• Choose colors that all color vision types can identify easily. In the design process, determine which hues and shade combinations are problematic in terms of their perception or differentiation, and avoid them. Refer to the available Web resources to help determine a color palette that is suitable for different types of color blindness, and to proof your color palette. Usually, if you increase the contrast between the brightness of colors, even when their hue and saturation are different, they can be discerned more easily. Note: See the resource list at the end of this article.
• Ensure that color is not the only differentiating cue. When designing for a Web site or the interface of a software application, use explicit text labels, shapes, line borders, or textures. Ensure that there is sufficient contrast between the text label and colors. Black text on a white background is prevalent because it provides good contrast for differentiation.

 
  Shapes and text labels help with the differentiation of items.

• Explicitly identify a color whenever its identification is useful and could be misinterpreted. For example, to ensure that a color can be accurately identified, regardless of the context:
  • Add the color name to a bar code tag for an item of clothing.
  • Ensure that a crayon contains the color on its label, and imprint the color name in the crayon wax in case the label is torn off.
  • Print the color of the plastic insulating covering of a wire every few inches along its length.
    
  • Use a tooltip to identify the color by name (or its RGB value).
    
• Add a color blind test to your regular set of accessibility checks for your product. Test the colors that play a critical role in any aspect of the design of your product. Consider involving one or more color blind testers, each with a different type of color blindness. In the early design process and during usability evaluations, ensure that your colors are distinguishable for their intended purpose in various planned contexts. The solution is often not as simple as substituting a color when a confusing color is critical to the color palette of a design. Sometimes it is necessary to evaluate various color palette options.  For software application and Web site designs, a number of utilities are available to help proofing how colors in the design appear to a person with color blindness. These utilities help to ensure that important colors are readily differentiated, and you can tweak any colors at issue. Minor color adjustments can make a huge difference in color perception for a color blind person.  Note:  See the resource list at the end of this article.
• Allow customization of the colors of user interface elements. Many software applications provide preferences for customizing the colors of various UI components, such as text, background color, and highlight color. This option provides the most flexibility for a color blind person. A few Web sites also provide the capability to change between a limited set of predefined color palettes to display their UI elements.

A poorly designed user interaction can unintentionally impede an otherwise efficient workflow. Likewise, the wrong color choice for elements of a design that you want users to distinguish greatly impedes accessibility for a color blind person. Make a difference for color blind people by considering these tips for your projects.

References

1. Adobe Creative Suite – Proofing Colors – Soft-proof for color blindness (Adobe Photoshop and Illustrator)
2. Designing for Color Blindness and Color Universal Design (CUD) – The Distinct Studios Journal.
3. Color Universal Design – Web site for the Color Universal Design Organization (mostly Japanese, but this link provides an overview in English).
4. Can Color-Blind Users See Your Site?  An article by Robert Hess for the Microsoft Development Network (MSDN), October 2000.
5. Color Oracle – A free color blindness simulator for Windows, Mac, and Linux.
6. Vischeck – A Web site that provides resources for simulating color-blind vision.
7. Visolve – A utility that transforms colors into discernible colors for the color vision deficient.
8. Designing for People with Partial Sight and Color Deficiencies  Aries Arditi, PhD. Guidelines for making effective color choices that work for nearly everyone.

 

 

Designing with the color blind in mind - Part 1

The limitations of color-blind vision

by Mark Jamieson

I’m color blind. When I divulge that information to people with normal color vision, they usually respond, “Really? Can you see any color? What color is this?”, as they point to something within close range.

This seemingly innocuous reaction indicates a general lack of understanding and empathy for people who live with this genetic-based vision disability. Color blind people experience many barriers and frustrations when using items that are designed for people with normal color vision.

In this two-part series:
Part 1 provides information about color blindness and its limitations.
Part 2 provides tips to reduce design oversights that affect people with color blindness.

Most of the people with color blindness (about 8% of males and 0.5% of females) can see color in a reduced color spectrum compared to people with normal color vision. Color vision deficient is a more accurate term than color blindness. Only in rare cases does color blindness mean seeing the world in black and white, or through a range of gray tones.

From a physiological perspective, our eyes contain photoreceptor cells that are named rods and cones, based on their shape. Rods number about 120 million per eye, and sense light and dark. Cones number six to seven million per eye, are less sensitive to light, and sense more color. Each of three cone types senses one of three primary colors: blue, green, or red. The information that these three cone types receive, when combined, is what our eyes perceive as color.

In people with a color vision deficiency, one or more cone types is malfunctioning or missing. As a result, they cannot distinguish as many color hues as someone with normal color vision.

The relative lighting (bright, dim, daylight, incandescent, fluorescent), background (light, dark, front lit, and backlit) and size of the color sample all play a role. A color blind person can generally see all primary color hues (red, green, and blue) at full strength (saturation). But the mixture of the deficient hues with other colors makes some colors challenging to identify, or indistinguishable from another.

Contrast is a huge factor in accurately differentiating between color shades. Color gradients (color ramps) are tricky too. One end of the ramp can begin in a hue that is perceptible, and end in a hue that is not. If text appears on top of the color ramp, it is sometimes not readable if the contrast between the elements is not high enough.

The two rows of colors in the following image provide examples of solid colors that can challenge some people with red-green color blindness.

It is relatively easy to differentiate (not identify) the five colors in either horizontal row, as there is good contrast and variation between the color hues.

To the red-green color blind, the colors in the vertical columns are almost identical, depending on the context in which they appear.

As the palette for a pie chart, these ten colors are problematic for most people with red-green color blindness, which is the most common color-vision deficiency.

Anything that involves identification of an item purely by its color can challenge a person with color-blindness. (Examples: matching clothing, plant foliage, signage, LED indicator lights on electrical devices, matching paint colors, colored pencils/crayons, Web sites, user-interface icons, color-coded information charts, board games, sunburn and rashes, insulation colors on electrical wires, maps, GPS color displays).

Color is often used as an element to simplify and differentiate items in the design of a product. Unconsidered color choices make the accessibility of a product more difficult and frustrating for a color blind person. We use color increasingly in the communication of information in many aspects of our society. We can easily reverse accessibility issues by designing products with colors that are perceptible by as many people as possible.

References

1. Colblindor – A Web site dedicated to color blindness, with many articles, and a free eBook.
2. We are colorblind – A Web site dedicated to making the Web a better place for the color blind.
3. Ishihara Color Blindness Test – The original Ishihara Color Blind test first published in 1917 as an online version.
4. Testing Color Vision – Advice for parents and teachers in dealing with color blind children.

Alerts and Warnings: Is your UI crying wolf?

by Cecilia Farell

We all remember the story of the boy who repeatedly tricked the villagers into thinking a wolf was attacking his sheep. When the wolf’s attack became real, no one believed him. The moral of the story is don’t squander your credibility, and it’s a lesson that applies to user interface design as well as human behavior.

If an application raises the alarm about every little thing that might happen or go wrong – if it “cries wolf” – its alerts and warnings gradually become meaningless and lose their intended effect. Worse, they can become annoyances or even hindrances to the user, who then ignores them or, if he can’t, ends up hating them.

Alerts and warnings:  error messages by any other name?

My last post was about error messages and how to make them effective. I mention this to emphasize that alerts and warnings are not the same as error messages.

Error messages occur “after the fact” and show the user how to navigate away from the problem and get back in the flow. Alerts and warnings are about problems that might occur in the future. Their intent is to prevent these from happening in the first place or, if that’s not possible, to mitigate their impact (think “preemptive damage control”).

Alerts “alert” and warnings “warn”

There is a difference between alerts and warnings, although it’s a subtle one. Alerts are a kinder, gentler version of warnings (think yellow traffic light instead of red). They inform more than they warn and are not fatal or even critical. An alert is the right way to let users know of upcoming downtime for maintenance or that the site login process has changed.

A warning is an absolute must when the user has to act (or refrain from acting) to avoid the loss of:

• mission-critical data
• access to the system
• privacy or control over confidential information
• the user's time (a significant amount) ¹

Going with “the flow”

The Holy Grail of UI designers is to create experiences where the user becomes “fully immersed in a feeling of energized focus, full involvement, and enjoyment.” This is known as flow, a psychology concept with recent application in the field of Human Computer Interaction, particularly in Gaming.

Flow is completely focused motivation. It is a single-minded immersion and represents perhaps the ultimate experience in harnessing the emotions in the service of performing and learning.²

If flow is the Holy Grail, breaking it is anathema. Unfortunately, alerts and warnings do just that. In fact, breaking the flow is what they live for: their job is taking the user’s focus away from what she’s doing and towards something that needs her immediate and undivided attention.

This is the very reason for using alerts and warnings sparingly and judiciously. In a nutshell, avoid them unless absolutely necessary. Apple’s guidelines³ declare alerts unnecessary if they merely:

• increase the visibility of information already available
• update users on tasks that are progressing normally
• ask for confirmation of actions initiated by the user
• inform users of errors or problems they can do nothing about

Red light/Yellow light

Earlier I suggested you think of yellow vs. red traffic lights as a way to differentiate alerts from warnings. Red and yellow (and of course green) are common colors in UIs because their significance is universal.

Using these colors in alerts and warnings is an effective way to grab your user’s attention and quickly convey the severity of what’s involved. When you combine these colors with equally significant symbols or icons, you can replace redundant Alert and Warning labels with more specific and meaningful content (e.g., Scheduled Downtime or Malware Detected).

 

Green light

These are simple guidelines to follow when crafting alerts and warnings. I’ve also stressed the importance of using caution and good judgment when giving an alert or warning the green light, so to speak. Before making that decision, ask yourself: Is this alert or warning worth interrupting the user’s ever so elusive state of flow?

Until next time and happy trails.

---

¹ Adapted from a list in the “Messages” section in Windows User Experience Interaction Guidelines. http://msdn.microsoft.com/en-us/library/dd535525.aspx.

² Both quotes are from the Flow (psychology) page in Wikipedia. The second is the words of Mihaly Csikszentmihalyi who, together with J. Nakamura, proposed the concept. http://en.wikipedia.org/wiki/Flow_(psychology).

³ Pared-down version of the list in the “UI Element Usage Guidelines” section of the iOS Human Interface Guidelines. https://developer.apple.com/devcenter/ios/index.action.

 

Changing Cultures: Towards a Lean User Experience

By Joshua Ledwell

Autodesk development teams that once requested design specifications up front now are collaborating with user experience designers to design, build, and test software in rapid cycles. This incremental approach offers more opportunities to gather user feedback and optimize the product. Success depends on practicing “Lean” UX, in which designers stop attempting comprehensive documentation, and embrace “just-enough” design combined with constant iteration.

The idea of working lean comes from “Lean Manufacturing” at Toyota and more recently The Lean Startup by Eric Ries. Lean companies minimize wasteful business processes that don’t add value for end user. They also get products to customers faster, even with fewer features, so they can learn from their target audience and build the most value into the next version.  

I am a passionate believer in Lean UX, so I was pleased to attend the Lean Day UX conference in New York on March 1. In the morning, seven speakers from different industries described how they navigated the switch to Lean practices.

Key insights from these speakers:

• Ries’ The Lean Startup treats product development as a series of quick, experimental launches. However, transitioning an organization to this lean workflow requires a cultural shift from “experimenting to validate” to “experimenting to learn.” As a UX professional, you may be accustomed to usability testing a complete product. Now, though, you may need new methods to help the product team quickly adapt to user feedback.
• Changing mindsets is critical for Lean UX success, but it’s not easy. Simple rules can help change your organization’s behavior. One speaker’s group outlawed surveys and mandated that all teams meet face-to-face with real users.
• At another speaker’s business, the priority is building lean entrepreneurial teams that take risks and learn from them. To help achieve this goal, managers at this company must present failures and suboptimal outcomes to the entire organization.
• Designing for delight requires building user empathy on your team. One recipe for success is generating many ideas and iterating solutions, moving from broad to narrow focus as you learn more about user needs. “Delighter” features create promoters for your product and brand.
• To paraphrase Bill Scott of PayPal, Agile is a good “engine” for delivering products, but it has no brain. Lean UX leadership can be the brain that ensures the team builds the right product. (see image below.)

After lunch we participated in a rapid prototyping exercise. My team designed an app for public transportation users to refill their passcards anywhere. We focused our design time deciding exactly what user problem to solve and how little we could build to solve it – also known as Minimum Viable Product (MVP). I was impressed by the POP app for iOS for rapid mobile prototyping. With this app you can photograph your paper prototypes, select hotspots for navigation, and link them into a flow.

Here are links to the presenters’ topics. Some of the presentations are online, and links are provided:

Lionel Mohri, Intuit: Getting Dirty With Design Thinking - How Intuit Is Enabling a Culture of Entrepreneurship and Experimentation

Farrah Bostic, The Difference Engine: Research Rebooted - Why Most Market Research Is Broken, And How Lean Can Help Fix It

David Panarelli, LivingSocial: Iterating Forward: Maintaining Alignment and Focus Across Multiple Lean Teams

Tom Illmensee, Snagajob: Build A Recipe For Better UX Process With Fresh Lean Ingredients

Andrew Crow, GE Healthcare: One To Many: Designing For Scale

Emily Holmes, Hobsons: Iterative Innovation – Small Guerilla Projects Can Lead To Big Successes

Bill Scott, PayPal: Lean Engineering: Key Principles For Transforming Engineering Into A Full Lean UX Partner

On the train back to Boston, I reflected on the speakers’ ability to promote user-centered change in their organizations. When UX professionals are willing to abandon potentially wasteful up-front design practices and embrace lean workflows, they are leading by example and increasing their influence on the whole organization. I like that being a change agent and a user-centered designer are mutually reinforcing aims.