Designing the User Experience at Autodesk

Method 24 of 100: Ideation Innovation: New Takes on Brainstorming

100 User Experience (UX) Design and Evaluation Methods for Your Toolkit

by Chauncey Wilson

This post will be different from previous ones that focused on only one UX method. Today we will look at ideation innovation and highlight three variations on traditional, face-to-face brainstorming – cheatstorming, extreme input, and DesignLibs.  

Cheatstorming 

In traditional brainstorming, a group will generate ideas and then choose which ones should be considered further using dot voting, ratings, specific criteria, or another technique for choosing the “best” ideas. When a new topic emerges, this brainstorming process is repeated.  In my experience, the ideas from one brainstorming session are not reused.  In cheatstorming, a method proposed by Faste and colleagues from CMU, the ideas from earlier brainstorming sessions are re-used.  The ideation phase where a group tosses out ideas is skipped in cheatstorming and the focus is on choosing ideas from earlier pools of brainstorming ideas.  The basic procedure for cheatstorming is:

1. Make the ideas from previous brainstorming sessions available.
2. When your team is ready to brainstorm on a new topic, pull a sample of random ideas from the earlier brainstorming results.
3. Record the ideas that best relate to the new topic.

So, in cheatstorming, no new ideas are generated; old ideas are applied to new brainstorming questions. 

Extreme Input 

At CHI 2013, Arne Janse and his colleagues presented a paper on the use of “extreme” inspirational material – sketches, personas, mood boards and scenarios -- for brainstorming.  They presented extreme ideas (e.g., a device that indicated bank balances by squeezing your arm to the point of pain), extreme characters (a washed-out actor), and extreme personas (a gaming addict) to members of a brainstorming team and then assessed the number of original ideas generated in the extreme conditions versus a control that used non-extreme ideas.  The preliminary results provide evidence that using extreme ideas as inspirational materials led to more original ideas.  The underlying principle for brainstorming with extreme input is that the extreme examples can broaden the space of ideas and lead to insights that might be missed using conventional sources of inspiration.

DesignLibs  

Jared S. Bauer and Julie A. Kientz of the University of Washington developed an ideation technique called DesignLibs that is loosely based on Mad Libs™, a game where you are prompted to enter particular categories of information into blank fields. The information is then used to create a humorous or provocative short story or scenario. Bauer and Kientz tested three types of DesignLib concepts for generating novel, inspirational scenarios.  The most successful technique required participants to “fill-in-the-blanks” of a scenario like the example below.

Blank Scenario

_________ is a ___ year old __________ who is somewhat chubby and struggling to get in shape.  He/She decides to lose weight by trying a _______that can be worn on  _____________ and provides ______ while ________.   

Filled-In Scenario

Chauncey_______ is a ___63___ year old _UX Architect_________ who is somewhat chubby and struggling to get in shape.  He/She decides to lose weight by trying a _pedometer_______that can be worn on  _his wrist______________ and provides __tactile encouragement_____ while _tracking exercise_______.    

The result of this DesignLibs technique is a set of novel usage scenarios as well as potential requirements.  In this example, the entry, “tactile encouragement,” might prompt a designer to consider a device that vibrated to signal that a goal had been met during a workout. This ideation method is easy to use with remote users and provides insights for conceptual design.

Summary

I described three edgy ideation methods from CHI research that push the boundaries of UX methods. The next post which will examine “hybrid focus groups” which combine usability testing, polling, reviews, and prioritization exercises with group interviews.

References

Arne Jansen, Nicky Sulmon, Maarten Van Mechelen, Bieke Zaman, Jeroen Vanattenhoven, and Dirk De Grooff. 2013. Beyond the familiar?: exploring extreme input in brainstorms. In CHI '13 Extended Abstracts on Human Factors in Computing Systems (CHI EA '13). ACM, New York, NY, USA, 1347-1352.

Haakon Faste (2013). Chainstorming! Cheatstorming!. Retrieved August 7, 2013 from http://crowdresearch.org/blog/?p=5345

Haakon Faste, Nir Rachmel, Russell Essary, and Evan Sheehan. 2013. Brainstorm, Chainstorm, Cheatstorm, Tweetstorm: new ideation strategies for distributed HCI design. In Proceedings of the 2013 ACM annual conference on Human factors in computing systems (CHI '13). ACM, New York, NY, USA, 1343-1352.

Jared S. Bauer and Julie A. Kientz. 2013. DesignLibs: a scenario-based design method for ideation. In Proceedings of the 2013 ACM annual conference on Human factors in computing systems (CHI '13). ACM, New York, NY, USA, 1955-1958.

Remote Site Visits: How to Do Field Research Without Ever Leaving the Office

By Alison Kather

Visiting a user’s environment is a practice that many UX professionals try to integrate into the user centered design process. Traditionally, ethnographic research projects can take a considerable investment of time and resources. By conducting the research remotely, however, you can work around the barriers of travel and recruiting, making it a little easier to pull off.

The terms “remote” and “site visit” often would be considered contradicting things, but they do not have to be.  So how can you visit a person’s environment without physically being there? Here are a few tips to help you modify your existing field research method into a remote one.

Tip #1: Figure your tools out first.

Your study format will be dependent on what tools you have available. Make sure you have this squared away as soon as possible. We have found that a web meeting with screen sharing capabilities works very well for people who are sitting at desks. If the person is moving around, a webcam might work. Consider that you may need people to have tools available on their end as well.

Tip #2: Give the person some prep work.

Making sure the participant understands what you want to learn before you visit them is critical. Since you will be remote, you are going to need to rely on them to share their environment with you. What you have them prepare will depend on your area of focus. Some ideas that might work:

• Photo & video assignments: Have the person take pictures or videos of their workspace, themselves, coworkers, and any other relevant area of interest. With the prevalence of smartphones, this is usually a pretty easy task to assign a user. Instruct them upload the photos to their computer to review when you meet or have them send you the files beforehand.
• Set aside work to perform during the visit: You can ask the person to save some work to be done on their computer while you watch them using screen sharing. 
• Reenact a scenario: Have the person brainstorm some recent problems or a scenario of interest. Instruct them to gather all the examples they will need to re-tell the story to you start to finish. Encourage them to gather artifacts like screenshots, photos, and emails.
• Gather examples for a show-n-tell: Ask for examples of artifacts that they can share with you. One drawback to this approach is that sometimes you don’t know what to ask for.

Tip #3: Have a quick chat with each person before your visit.

Briefly speak to the person on the phone before your scheduled visit to explain the goals of the exercise and instruct them on how to prepare. It also gives you a chance to get a sense of who they are. This will help you understand them more easily during the actual visit.

Tip #4: Make sure the person is in the right location.

Try to have your participant be in the physical location that you want to learn more about. Be extra clear about where and how you want to conduct the visit remotely. It should be as if you were really visiting in-person even though you are remote.

Tip #5: Build in extra time to get to know the person’s environment.

Leave a considerable amount of time in the beginning of your remote visit to have the person describe their environment. If the person completed a photo assignment, review the images with them using screen sharing. If you are using a webcam, get a live tour. If no visual aids are possible, ask the person to describe in detail what they see around them. Make sure to leave no stone unturned. There will always be unexpected clues that will help reveal more about that person and their location.

Try it out and see: Although nothing can replace actually being in a person’s work environment, hopefully with these tips you can set up your research to come pretty close. Note that you still need some sort of field research plan to begin with, these are just tips on the logistics.

Remote research can open doors to new types of people and environments that were once closed due to travel restrictions and recruiting obstacles. It also makes things a little easier visiting people and never having to leave the office!

RITE, C-RITE and Traditional Usability Testing: What’s the difference?

By Veronica Meuris

At UxPA this year, I attended a presentation titled: “C(ollab) RITE: How to run impactful iterative studies in a fast paced environment” by two researchers from Google.  My team at Autodesk already conducts quick, collaborative, iterative, formative usability tests similar to RITE, so for me the question was: what’s the difference between traditional usability testing, RITE, and C-RITE?

Traditional or summative usability testing involves recruiting representative users, defining key tasks, determining a test protocol, testing with users utilizing think-aloud protocols, and recording observations.  Brainstorming solutions to problems and re-testing or redesign work feed into the next design cycle rather than into the current usability test phase. Collaboration between stakeholders may also be quite limited.

Traditional Roles in Usability Testing and Design
(All images in this article were created by Roeber, H., Jain, J. (2013). C(ollab) RITE: How
to run impactful iterative studies in a fast paced environment.
The title of this image has been modified.)

RITE (Rapid Iterative Testing and Evaluation), developed by Microsoft® Games Studios and Microsoft Research (2002), like traditional usability, involves representative users engaging in real tasks with the product.  Test sessions are observed by product team stakeholders. Users ‘think aloud’ as they interact with the product.  Observations are recorded and following each test session, are discussed and agreed upon by all product team stakeholders.

Unlike traditional testing however, all stakeholders are involved in prioritizing problems observed and identifying solutions to usability issues. Moreover, problems are identified, iterated upon and fixed quickly within the current usability test phase.

For more on the RITE process, how and when to use it to find and fix usability problems, refer to Chauncey Wilson’s recently published DUX article on this topic.

C(ollab) RITE or C-RITE is an extension of the RITE method that uses stakeholder collaboration throughout the entire user-centered cycle vs. just observing and discussing test sessions and brainstorming solutions as they would using RITE.

C-RITE maximizes the impact of RITE by ensuring cross-disciplinary collaboration on planning, research observation, analysis, and design exploration within an agile, user-centered development framework.  

Collaboration in C-RITE

Given C-RITE’s extensive collaboration throughout the user centered design process, Google can recruit representative users, plan tests, design and test their content, iterate it and prototype designs for their next cycle within a week or so. This is much faster than both traditional usability methods and RITE.

Traditional usability timelines compared to RITE and C-RITE:

Most of us likely engage in some combination of traditional and RITE methodologies as needed to ensure we get user feedback to inform our design decisions.  Given that traditional usability testing is summative or ‘out of box’ and thereby tests an entire application, the testing and design process is quite involved and time consuming.

Traditional Usability Testing and Design Time Line

With RITE methodology, collaboration during the test and design phase allow for that part of the process to be completed more quickly than with traditional testing.  A potential problem with RITE though is how challenging it can be for stakeholders to commit to 1-2 weeks of involvement.  

RITE Time Line

C-RITE addresses this issue by reducing the collaborative work into 2.5 days per week. In that time, design problems are researched, analyzed, reported, prioritized, designed for and prototyped. If a cyclic C-RITE process has been adopted, i.e., repeating it weekly or biweekly, the planning and recruitment phase of the process can be shortened, further shrinking the timeline.

Cyclic C-RITE Time Line

RITE and C-RITE have distinct strengths and weaknesses over traditional usability testing.

Strengths:

• Gets the entire team engaged in the process
• Allows for quick design iteration, reducing ‘fear of failure’ that designers may hav
• Stakeholders will be highly motivated by the opportunity to express opinions on what they’ve observed
• For the Design Lead/Owner, being able to listen to and build on others’ insights makes for richer design discussions

Weaknesses:

• Full time recruiting support is needed to ensure a continuous pool of participants
• Involves a time commitment and steady involvement from all stakeholders
• Some changes may not be possible in the short iteration timeframe based on software/UI architecture

RITE and C-RITE provide a quick feedback loop where user insights are adopted quickly, product teams are provided with a clear sense of progress, and user centered design advocates are born.  

References:

Medlock, M.C., Wixon, D., Terrano, M., Romero, R., & Fulton, B. (2002). Using the RITE method to improve products: A definition and a case study. Presented at the Usability Professionals’ Association, Orlando Florida.

Roeber, H., Jain, J. (2013). C(ollab) RITE: How to run impactful iterative studies in a fast paced environment. Presented at the User Experience Professionals’ Association, Washington DC.

Shirey, J., Charng, A., & Nguyen, Q. (2013).  The RITE way to prototype.  UX Magazine. Retrieved March 19, 2013 from http://uxmag.com/articles/the-rite-way-to-prototype.

Method 23 of 100: RITE Method

100 User Experience (UX) Design and Evaluation Methods for Your Toolkit

by Chauncey Wilson

This is the 23rd in a series of 100 short articles about UX design and evaluation methods. Today, I will discuss the RITE method for finding and fixing usability problems.   The RITE method is a variation on traditional think-aloud usability testing where problems are fixed during the usability test phase and then retested to validate that the solutions improve usability. 

The RITE method, because of the rapid find and fix approach, is potentially a better match for agile development than traditional usability testing.

Method 23 of 100: RITE Method

The RITE method is generally attributed to Microsoft® Games Studios and Microsoft Research. The RITE method uses representative users, real tasks, observation of participant interaction with the product, and thinking aloud. The primary differences between traditional usability testing and the RITE method (Medlock, Wixon, Terrano, Romero, & Fulton, 2002; Medlock, Wixon, McGee, & Welsh, 2005) are:

• Fixes are made as soon as a problem and clear solution to that problem are identified.  An obvious problem with a clear solution might be fixed after a single participant.
• The product team must be able to fix problems quickly – say within a day.
• The team must agree on what tasks every user of the product must be able to perform to help set the priorities for problems that emerge during the testing.
• The product team must include time at the end of each testing day to make sure that fixes to problems have improved the usability of the system and have not introduced any new problems.

There is no fixed number of participants. Iterations often consist of 1 to 3 participants.  The testing goes on until all fixes are verified to improve usability.

When to Use:

You can use the RITE method to:

• Find and fix problems quickly
• Support an agile process
• Involve the entire team in making the product usable

Strengths and Weaknesses:

+  Gets entire teams engaged in the find and fix cycle

+  Keeps decision-makers directly in the loop about the usability of the product

+  Provides rapid identification or problems and solutions 

-   Strong recruiting support is needed to keep a constant flow of participants

-  Requires a strong team commitment to have the entire team go through the RITE process

-  The software/UI architecture of the product or service may not easily allow quick changes

-  Rare problems may not emerge during RITE testing

-  If there are many problems and many fixes, some solutions might break the same or different parts of the product

Procedure: 

The basic RITE procedure is:

• Get commitment from the product team and decision makers to observe test sessions.
• Get the team to agree to fix usability problems as they emerge from testing.  Include time in the testing schedule to fix emergent problems.
• Define the metrics of success.
• Choose representative users, define key tasks, and develop the testing protocol.
• Conduct the test sessions using a think-aloud approach.
• Analyze the data after each session.
• Review the problems that emerge after a session.
• Brainstorm solutions to problems.
• Agree on the best solutions and fix problems. If the team is not sure that they understand the problem continue testing the current UI until the problem is clear.
• Retest fixes and validate that the fixes did not introduce any new usability problems.

References:

Medlock, M.C., Wixon, D., McGee, M., & Welsh, D. (2005). The rapid iterative test and evaluation method: Better products in less Time. In Bias R., and Mayhew, D.J. (Eds.), Cost-justifying usability: An update for the Internet age (489-517). San Francisco, CA, USA: Morgan Kaufmann.

Medlock, M.C., Wixon, D., Terrano, M., Romero, R., & Fulton, B. (2002).Using the RITE method to improve products: A definition and a case study. Presented at the Usability Professionals’ Association, Orlando Florida.

Patton, J. (2008). Getting software RITE.  Retrieved July 15, 2013 from http://www.agileproductdesign.com/writing/ieee/patton_getting_software_rite.pdf

Shirey, J., Charng, A., & Nguyen, Q. (2013).  The RITE way to prototype.  UX Magazine. Retrieved July 15, 2013 from http://uxmag.com/articles/the-rite-way-to-prototype

Sullivan, B. K. (2011).  5 ways to improve your next agile project with the RITE method. Retrieved July 15, 2013 from http://bigdesignevents.com/2011/08/5-ways-to-improve-your-next-agile-project-with-the-rite-method/

Sustainable User Experience in the Clouds - Part 3

by Kem-Laurin Kramer & Stephen O'Connell

In Part 2, we discussed the concept of SaaS and universal design & service liberalization challenges for design. In this post, we continue discussing additional challenges that designers need to be cognizant of to create optimal user experiences that meet a wider mass appeal.

The challenge is to think of ways to keep the interest of expert users and allow them to grow but at the same time nurture less knowledgeable users. Reaching that design balance will be the challenge of user experience as we think of the delivery of one solution for all.

New devices

Not only are we going to attract a new user group, we are also going to interact with users through a plethora of devices and modalities. These new users often come from a myriad of desktop applications; all with different terminology and interaction styles. The challenge for designers is to continue to support experts but also provide a user experience that offers a fast learning path for new users, no matter their previous software experience or the devices and interaction from which they will access our solutions.

The Value of Intangibles: User Financial considerations

In the context of Autodesk business, many users are interested in Media & Entertainment creation suites and/or individual products, but cannot justify the cost of purchasing professional level software as they would only use it for a small portion of their work. For many customers the reason to move to SaaS is that it often offers a fee model that does not require heavy upfront investment and can scale as you grow. The lower cost of entry is more likely to attract new users who were previously discouraged by the upfront cost.

From a UX perspective we need to think about what it means to bring a large group of users from disparate applications together and in a short amount of time get them all to be productive using our software.

Multiple vendors, Trust, Collaboration & Social

Overall the user experience is defined by the interaction between the software and the end user, but with cloud applications some new actors enter the relationship. This includes the hosting provider, storage provider, browser provider, and ISP to name a few; all of these aspects influence the user experience.

While we are dependent on 3rd party vendors, the relationship is still between the customer and us. We are therefore responsible for the whole user experience and vendor’s problems reflect directly on us.

Another challenge the UX must address is building confidence in remote storage and processing. User interactions must be quick and responsive and where processing is happening, the user must be made aware and progress indication shown – the user should not be left to guess if the application is simply not responding or has crashed.

Last but not least, as we design we need to remain acutely conscious of the natural human tendency to collaborate and connect. While each design project dictates different levels and definitions of “social”, this is an ever present element and the new mainstay of web services today. In a nutshell, the user experience challenge as we move to a SaaS model can be summarized in the following guiding principles:

As we begin to understand this new landscape in all its intricacies, we are one step closer to building optimal user experiences. We take into consideration the spectrum of users, devices, and the concepts of service value, as well as the wider implications of interoperability. We are now on a playing field where user experience factors are shaped by many things out of our control but are owned by us.

Sustainable User Experience in the Clouds – Part 2

by Kem-Laurin Kramer & Stephen O'Connell

In Part 1 of this blog post series, we discussed the concept of Cloud-Aware User Experience Thinking and what it means for the traditional UX practice.  Cloud-Aware User Experience focuses on the transformed environment of cloud service delivery and how it impacts the overall user experience. In this post, we’ll discuss more areas that need consideration as we design solutions for cloud delivery: 

1. Understanding the concepts of Software as Service (SaaS);
2. Understanding universal design & software service liberalization and the multi-layered impact of web services liberalization and what it means for the changing spectrum of users;
3. Understanding the changing expectations and values that users associate with cloud service delivery.

SaaS: From traditional software to SaaS

SaaS (Software as a Service) often refers to an "on-demand" software delivery model in which software and its associated data are hosted on the cloud, as opposed to the traditional mode of delivery, where software was hosted on individual user machines.

Today, SaaS is quickly becoming the most common delivery model for application delivery, including Autodesk’s own suite of products.  Instead of being confined to their desktops, users can now log in anytime, anywhere and on any device.  This also means a gradual departure from the purchase of physically packaged and downloadable software to usage of hosted solutions. Hosted services also come with fewer limitations on such things as cost. Further, SaaS has built-in scalability capabilities for users seeking more flexibility of use.

Universal Design & Service Liberalization Challenges for Design

As technology matures, there is a tendency for initial software complexity to give way to simplicity as the audience broadens. In the automotive world, for example, a good contrast is manual transmission being available for enthusiasts, but automatic transmission being pitched to the mass audiences, with both options allowing end consumers to accomplish the same end goal – the act of driving. In much the same way, service delivery to the cloud is going to broaden our audience; therefore, we must be ready to support users who know what they want to achieve without the burden of committing to months or years of software training. Retaining a wider audience requires that new users can become quickly productive, quickly achieving their goals and having a path to grow their knowledge organically.

The migration to the cloud holds the potential to on-board a wider audience, but we can’t forget, as designers, to maintain the interest of users who may view the widening access as a threat to their jobs. In many cases, end users have used the technological divide as a means of self-identification for work purposes. Much like a developer who may describe himself as a JAVA or C+ developer, the same holds true in the space of 3D, where many certified solution users may have gone through years of training to use a title associated with a product line. However, as we see  more software being delivered via cloud services there will be significant changes in how users will see their relationship to software as a whole as well as how we should go about designing appropriate experiences for this technological divide.

In Part 3 of the blog we continue on this thread of creating mass appeal user experiences for software cloud delivery as well as some of the other challenges that we will encounter as experience designers.

Building Trust: AutoCAD Customer Councils

by Melissa D. Schmidt

On the AutoCAD UX team, we've been thinking a lot about building trust with our customers.

We've recently transitioned our software development process from waterfall to Agile. As a result, we are getting closer to having smaller, working chunks of code that we can show to customers sooner.

We have designed a Customer Council program as a way to partner with customers throughout the development of our key features. AutoCAD has a very broad user base from nearly every industry. So for each Customer Council, we carefully select people who have a vested interest in a particular feature area, and invite them to participate in our development process with us. Through the council, participants get to preview very early builds of AutoCAD that have partially complete functionality, revealing the direction we're going. They can try the functionality out on their own drawings and projects, give feedback, and watch the features evolve. This gives customers much earlier exposure to the actual implemented solution. The big win for us is that we can get feedback in time to make really meaningful changes.

Sample welcome email after joining an AutoCAD Customer Council

 

Often, with AutoCAD, you have to wait until everything comes together to get a good understanding of the experience that a user will have. Unlike a website, in which interactions are often linear and decoupled, the AutoCAD experience is an immersive design canvas with complex, highly-precise interactions, relying on a sophisticated graphics system. If performance is slow or the code isn't stable, it will drastically interfere with our users’ experience and we will lose the sense of how they would really behave. For example, with slow performance, you see cognitive step-down effects that cause users to lose their concentration and shift focus. In cognitively demanding tasks like design, this breaks our users' flow and dramatically changes how they work.

We've noticed that sharing these early bits of code with customers is like exposing your soft underbelly. You know the code isn't rock-solid, and there will be bugs and quirks and probably crashes. You can't hide the buggy areas with a well-practiced demo, or a controlled usability session. You are releasing the code over to customers to try out on their own, in the wild, to do whatever they might with it.

To do this, you have to be willing to be more vulnerable. This is where trust comes in. We don't want to let our customers down or to disappoint them. We're also aware that the first impression is crucial because it can anchor our users' perceptions and expectations in the future. These concerns are in direct conflict with the goal of letting users into the inner chambers of our design process, allowing them to co-design with us, and observe the work in progress as it comes together.

In spite of the discomfort of being exposed, we are learning to be more vulnerable. So far, we have found that many people are willing to work with us from this early stage.  They are prepared to put up with the bugs and crashes in return for being able to help guide and influence the functionality so that it gives them what they need. And through this process we are building trust.

By partnering with our customers in a deeper way, we are building more human relationships. For example, we introduce the council participants to the relevant development team at Autodesk. We share names and pictures of people, have webinars and one-on-one phone calls. This helps us move beyond the perception of being the big company Autodesk, to just being people who are trying hard and doing our best, who will acknowledge if we make the wrong assumption about a feature or leave out something that is important.

We want to build something that users are thrilled to get their hands on and that will amplify their abilities to do even more amazing work. We are still in the early stages of learning with Customer Councils, but we are getting glimpses that we can get closer to our goal by letting users into the development process earlier.

Interested in participating in a customer council or other AutoCAD research? Tell us a little about yourself and we will contact you with upcoming opportunities!

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.