Recently I have tested several web sites that were functionally usable (often with a 0% task failure rate), but my clients wanted to know more. Were participants excited about using the site? Were they interested enough to possibly revisit the site on their own? Did they feel an emotional connection to the site that enforced the brand or that would compel them to choose this site over a competitor?

These types of research questions are often challenging for participants to honestly answer in a verbal interview setting. Participants may find it difficult to pinpoint exactly how a site makes them feel or may lack the words that adequately convey their reactions. They may give you the answers they think you want to hear, or they may focus too narrowly on specific elements and experiences they encountered during the session. In other words, they may not be able to see the big picture clearly enough to describe it in their own words.

Further, participants often may not know how likely they are to revisit a site. Although participants may say they will use the site again when they have a need for it, this does not tell us that they would actually want to use this site if they had an alternative. How do we measure this?

It is common to use the Net Promoter metric ("How likely are you to recommend this site to a friend or colleague?") to understand how well a web site "wows" users. The assumption here is that users only recommend web sites to friends and colleagues when they provide an exceptional user experience; thus, a high Net Promoter score indicates a high level of the "wow" factor that brings users (and their friends and colleagues) back for more, while a low Net Promoter score indicates a lackluster user experience that doesn’t encourage users to recommend the site to colleagues (let alone use it again themselves!).

A complementary method I like to use in understanding participants’ reactions and measure the presence of this "wow" factor is a reaction card sort. In this activity, which is based on the Desirability Toolkit developed by usability researchers at Microsoft, I give participants a stack of 60 or so cards containing a wide range of individual positive or negative adjectives (such as "beautiful" or "boring" or "novel"). The instructions are simple:

• Quickly go through the stack of reaction cards and create a pile of all of the cards that match your impression of the site.
• Create a small pile of these cards that most strongly convey your impressions of the site, and tell me a little about why you chose each card.
• (Optional) Create a pile of "anti-reaction" cards that represent the complete opposite of your impressions of the site, and tell me a little about why you chose each card.

Participants create piles of reaction cards that convey their impressions of the web site being tested

This method is highly flexible and adaptive to each project and client with whom we work. Although we start with a base set of cards that serve the needs of most situations, we can add or subtract cards to further reflect the project's research questions, the product's goals, or the brand image or mission of the client. The data collected from reaction card sorting is rich and fascinating. The words that participants choose (or don't choose!) provide an uncensored peek into how participants feel about the site being tested, and speak to whether the site delivers a wowing experience that is likely to encourage loyalty and repeat visits. We pair this activity with more traditional approaches such as task completion, Net Promoter scoring and open-ended interviewing for several reasons:

• It helps explain the "why" behind responses to interview questions and the Net Promoter score. For example, a participant's choice of reaction cards may shed light on why he or she expressed a lack of interest in visiting an easy-to-use site in the future ("it was boring, uncomfortable, and plain.").
• The variety of adjectives given to participants allows them to express themselves fluidly without the cognitive burden that often comes with responding verbally to interview questions. Specifically, the cards remove the need for participants to come up with the right words to describe how they feel. Working through the stack of cards often results in several "Aha! That’s the word I was trying to think of earlier" moments.
• It gets participants talking about the complex range of emotions they may feel about a web site without worrying that they are contradicting themselves or providing inconsistent feedback. For example, participants are able to use the cards to describe the content of a web site as "relevant," "comprehensive," and "convenient" while also describing the overall design as "busy," "distracting," and "ordinary."
• Because participants can quickly work through a deck of cards and choose as many cards as they would like, they seem less likely to censor themselves or only discuss their strongest opinions. Consequently, we are able to gather a comprehensive set of positive and negative impressions in much less time than may take with open-ended interviewing.
• This activity allows clients to subtly test out the efficacy of their branding or their product goals. For example, if the developers of a health information website seek to provide a fun and engaging learning environment for health information-seekers, we can include the words "fun,""engaging," and "educational" in the stack of cards. If participants choose these cards during the reaction card sort, we can infer that the client’s current efforts are on the right track to meet their goals.

When presenting findings, we find that word clouds do a great job of emphasizing the various dimensions of the user experience we observed in a study. The words that are chosen most frequently appear in the largest font size and typically represent the strongest opinions that participants expressed during the study. Starting here, we can share with the client their site’s biggest strengths and opportunities for improvement. The smaller words represent those that were chosen less frequently but still play an important role in describing how participants perceived the site. Often, the smaller words represent individual impressions (such as "unattractive," "disorganized," "annoying" in the example shown below) that explain or support the larger, more frequently-cited impressions ("busy," "distracting"). Brought together, these sets of words provide a visualization of participants' core feelings about the site in a way that clients can digest and respond to immediately. Word clouds are used to visually represent findings from reaction card sorts

Word clouds visually represent findings from reaction card sorts

References:

Measuring Desirability: New methods for evaluating desirability in a usability lab setting, Benedek, Joey and Trish Miner. Usability Professionals' Association Conference Proceedings (2002).

We worked with software startups and giants alike, new media agencies, insurance providers, a coffee company, a materials association, an industrial manufacturer, a high-end outdoor clothing company, non-profit and government organizations, a major television station owner, and a greeting card company, just to mention a few clients seeking to create better user experiences.

While it is difficult to neatly summarize a year of usability activities and generalize across so many domains, media types, and information spaces, here are some themes and issues that stand out.

Early concept testing pays off
A great interface can’t save a product whose conceptual model or value proposition does not resonate with users. Concepts can often be validated with users during early requirements phases via scenarios, storyboards, and rough renderings, but sometimes partially functional prototypes are needed to fully understand user reactions to a new concept.

• We worked with an exercise equipment manufacturer on some early product concepts featuring a new interaction model. Users loved and easily understood the concept, helping the company’s design team green light future work on the project.
• We tested a new software technology concept for an Intranet application. Unfortunately, this particular application of the technology bombed in its appeal and perceived usefulness when representative users interacted with it, but the study findings enabled developers to re-focus on more promising applications using the same technology
• We conducted user research and tested early web prototypes aimed at educating parents when their child faces a serious health condition and they need to evaluate treatment options. The conceptual prototypes compared very favorably against existing web-based materials, and we identified several improvements that would help serve parents’ needs even more

Card sorting remains a method of choice
At times, 2008 looked like the “Year of the Card Sort” in our usability labs. We used physical and online card decks to expose users’ thinking and help designers refine navigation categories and information architectures, determine content placement, and assess user satisfaction. Here are a few examples:

• An industry association was looking to add new content about green building and environmental qualities to their existing web site. Results from a card sorting study helped them develop meaningful category labels and place content where users could easily locate it.
• Open and closed card sorts helped an outdoor apparel company create an intuitive faceted navigation system for their web site reflecting how customers naturally group products together.
• We used “reaction card” techniques as a supplement to traditional usability methods in several studies in order to gather deeper insights about users’ experiences interacting with these systems. Participants sorted and selected cards listing positive and negative adjectives to articulate multiple aspects of their experience.

Web writers and editors: your work is not yet done
Last year we wrote tongue-in-cheek that Information Architects still have some unfinished work before the web is pronounced easy to navigate. This year we’re calling on web content writers and editors to step it up as well. Dense text is difficult to read, and we have frequently observed that users do not have the time and patience for it. Lessons learned: cut back on text until it hurts, make copy easy to scan, and use lots of visuals and white space. Test important text with users for comprehensibility.

A Blink eye-tracking study pinpointed a “hot spot” on this page where study participants struggled to interpret a difficult block of text. Understanding the information here was critical to the task at hand; most re-read this section numerous times while also expressing their confusion verbally.

Bilingual and international testing: bringing the message home
Blink consultants and partners conducted usability testing and user research in several other languages and countries last year. Through the aid of remote testing tools, we also conducted web conferencing feedback sessions and phone interviews across the US and in other countries.

• For development team members in a US home office, viewing video clips of their international customers using their product brought these users’ experiences to life. Although the team could not understand the language without the aid of subtitles, witnessing users’ frustrations through their tone of voice and body language effectively raised a sense of urgency, especially when international users noted aspects of competitive products that were a better local fit.
• Web sites designed for bilingual communities can pose unique challenges. While usability testing a site that was localized in Spanish, but linked to sites that were not always fully translated, we found that US-based native Spanish speakers were generally forgiving, though somewhat surprised when site content switched to English. To reduce the jarring impact of jumping from one language to another, users suggested placing clear signposts to indicate when linked sites are not localized.
• While remote usability testing or user research does not substitute for in-person testing or observation, remote interviewing tools have greatly improved. These tools can reduce project costs, and can greatly broaden the geographic scope of feedback. In a single day last year, we conducted usability testing with users in Sweden, Finland, Canada, New Zealand, and Australia.

Users are giving video a second chance
YouTube and other user-generated media sites are having a positive impact on users’ attitudes and receptiveness to video. In the past, study participants frequently ignored video clips when testing non-media focused sites, telling us they expected “marketing fluff” or messages that presented a biased or overly simplistic view. Another common turnoff was that video was slow to run on some systems. This perception is changing.

• One of our usability clients presented 1-2 minute video tutorials while their software was installing and indexing files on users’ systems, a required and relatively lengthy process. Participants appreciated having something informative to do while this indexing took place, and the videos took advantage of a “teachable moment” to convey some basics before users had direct access to the software tool.
• A cruise line site we tested encourages cruisers to upload videos on its YouTube video channel as a way to help promote trips. Other sites are doing similar things to leverage the power of our newfound fascination with creating, sharing, and consuming video content.

YouTube has taught us is that video does not need to have high production quality with a professional talking head to be effective. Training videos can even be perceived as more authentic if they feature a company’s own personnel performing example tasks or walking through key scenarios.

Avoid giving users a confusing ride on your carousel
In an effort to squeeze more content on web pages, designers sometimes turn to novel navigation features such as carousels that advance or rotate objects in a fixed space. These are great for displaying related products or showing facets of the same product, such as pants presented in different colors or with different tailoring options (cuffed or not, straight vs. relaxed cut, etc.). Some carousels are relatively simple slide-show-like implementations, while others present selectable objects in a 3-D, circular view.

This carousel, used on Amazon.com, effectively displays related products within a small space. It clearly communicates the total number of pages or items available.

When using novel interaction such as a carousel, web site designers and content writers need to remember usability basics such as reinforcing a sense of place and keeping users in control. For example, common usability problems we have seen with carousels include:

• Users can easily lose track of what they have previously viewed when sites do not display how many items or sets of items exist or their current location within the set.

This type of carousel makes users work harder to remember which items they have previously viewed, especially if items are not visually distinctive or otherwise memorable.

• One site we tested displayed content below the carousel when an item was selected. Users were not always aware of which item was selected, and some did not associate the dynamic content with the carousel selection at all.
• Complex navigation within a carousel can be very problematic. Rich navigation is possible using a carousel model, whereby the carousel changes “pages” that each present their own set of navigation opportunities via links or embedded objects. We have seen users become lost or miss key messages within this type of navigation scheme. Interaction designers need to take extra care to convey location and navigation options through labels, headings, and other visual cues.

Make comparison shopping easy
Consumers have a strong desire to compare and contrast, whether they are shopping for a new camera or dental coverage. This manifests itself into questions such as:

• Which of these products is right for me and my specific needs?
• What exactly am I getting?
• Am I getting a good deal?
• How do payment options differ?
• How do I know my purchase and post-purchase service experience will be hassle-free?

Web sites we tested that provide tools and visuals for comparison shopping were well received, even when the company’s products involved an application process or were not immediately available for purchase online. Based on user feedback, we recommended improvements to several sites providing health care coverage, home and auto insurance, and retirement planning services:

• Use tables or side-by-side comparisons whenever possible so users can see at a glance how each plan or policy offered is different.
• Create ways for users to easily compare and contrast payment options.
• Provide easy access between products to avoid users having to re-trace navigation steps.
• Use straightforward and simplified language that gives users the confidence they need to choose between options.

Community features: create your own or leverage existing tools?
Many companies and organizations want to connect their users and engage with them online, whether it’s to answer support questions or create buzz around a new product. Adding social networking and community features such as user reviews and discussion/support forums to a site can be powerful, but at what point is it worth investing in your own features versus leveraging the infrastructure of existing social media sites such as Facebook, YouTube, LinkedIn, Flickr, and Twitter?

Last year we validated whether users were interested in community or social networking features in several web site experiences. We found out that users can be interested if the audience of a site is focused on a special interest not well-represented on mainstream social media sites, but that users are often leery about engaging in yet another online community when the tools they are currently using already connect them with people of like interests or opinions.

Bottom line: When budgets and resources allow, consider adding community features, but make sure to balance this need carefully against other site features and usability improvements.

There are a lot of professionals– lawyers, politicians, software developers and program managers to name a few – who "own" various aspects of online privacy in social applications. We believe that usability professionals are well suited to take a more active role to protect users and set standards for online privacy protection, addressing critical questions such as:

• What level of privacy should be set by default?
• How should users be notified about privacy settings and changes to them?
• When is it okay to share private information with others? How should this be supported?
• What tools are needed to allow users to control their private information and the audience who has access to it?

Why are usability professionals well-prepared to take on this role?

1. We are champions of developing and using reliable user research methods
When developing applications that allow users to manage, organize, or share private information, it is essential to understand users’ expectations and needs for these applications. Willingness to share, for instance, may vary significantly from one application to another based on how the shared information will be used or who may have access to it. Usability professionals are prepared to use our experience with user research methods to learn about unique needs and expectations and to make recommendations based on more than just a hunch. User research enables us to understand privacy implications before designing applications and lets us answer questions such as:

• What level of control and amount of privacy do users expect to have?
• What do users already do to maintain their privacy, both online and offline?
• What words do intended users use to describe privacy options?
• What do users NOT do to maintain their privacy?

Example: Flickr uses approachable terminology and a wide range of options intended to support users' privacy needs.

Further, we are in a unique position to develop new research methods to address opportunities that aren’t fully supported by our traditional toolkit. For example, there is a growing need to create privacy-specific sets of heuristics or guidelines (much like Jakob Nielsen and Rolf Molich’s often-used Usability Heuristics) for efficiently evaluating potential privacy issues in existing interfaces.

2. One of our roles is to advocate for the user
Organizations that develop applications with privacy considerations are bound to have a number of people involved in the development process. For example:

• Project managers make business decisions about the intended goals of the application.
• Lawyers ensure that the privacy policies are comprehensive and that business decisions are safe.
• Software developers turn business decisions into a reality.

These professionals provide necessary areas of expertise to the table, but they may not have direct contact with the users they intend to serve. Based on the research and studies that we conduct as usability professionals, we provide an unbiased source of knowledge about users’ needs and habits for all collaborators during product development. When developing a potentially privacy-invading application, a product team that employs the skills of a usability professional can access users’ points of view and behavioral habits to:

• Verify that the type of content being shared is what users are actually interested in sharing.
• Identify the types of privacy settings and the level of control that users want or need to efficiently manage their content and audiences.
• Validate that users can effectively use privacy-controlling features and settings.

Example: Facebook's settings are based on understanding the precise amount of control users need to safely share private content about their lives.

Further, usability practitioners are able to ensure that potentially privacy-invading applications literally speak the users' language. Our knowledge about users prepares us to check that terminology used in settings and instructions is consistent with users’ own vocabulary. Further, we can advocate for usability improvements to necessary documents that are typically daunting for users to read, such as privacy policies.

Example: Bill Monk's privacy policy shows how the influence of usability practitioners can make a traditionally dense and legal-heavy document approachable and easy for users to understand.

3. We can protect users from harm, even when they do not notice a privacy risk
The Pew Internet & American Life Project has reported that 60% of Internet users are not worried about the information that is available about them online. Even more disconcerting, only a small subset of concerned users actively does something to protect their privacy. A few reasons may account for this lack of action:

• Many people assume the information out there is not that personal or that no one important will be able to find it.
• Users do not like to read lengthy privacy policies, instructions, or help documents that tell them exactly what aspects of their privacy are at risk.
• Users often do not know how to protect themselves and find the available privacy settings or protocols cumbersome or irrelevant to their needs.

It is not necessarily our job to convince users that their privacy is at risk, nor is it our job to train them to become privacy experts. It is our responsibility, however, to ensure that applications limit or prevent errors and minimize risk. There are many things we can do behind-the-scenes to help prevent users from accidentally putting their privacy at risk. For example:

• Ensure that the application uses reasonable default settings.
• Advocate for potential privacy-invading settings to be opt-in rather than opt-out.
• Refrain from offering any seriously harmful or destructive options.

Example: Facebook minimizes privacy risk by automatically limiting the features available to minors.

Further, applying basic usability principles to the privacy domain will go a long way in subtly making users aware of their privacy risk and helping them make informed decisions without expertise or cognitive overload. Some examples:

• Use clear and consistent language around concepts relating to privacy, personal information, and sharing.
• Prominently display the status of privacy settings (“you are sharing your health information with the world”) throughout the application.
• Give users complete control over the private data they previously shared by letting them undo, unshare, or revoke access from others.

Example: Google Reader prominently displays the user's current sharing settings (who the user is sharing with and how many items are being shared) and provides options to modify or undo.

Recommended reading:

• End-User Privacy in Human-Computer Interaction
  Giovanni Iachello and Jason Hong
• Digital Footprints: Online Identity Management and Search in the Age of Transparency
  Mary Madden, Susannah Fox, Aaron Smith, and Jessica Vitak
• 10 Privacy Settings Every Facebook User Should Know
  Nick O'Neill

• Where, when, and how will users engage with the system? How does this constrain the type of interaction that is possible?
• What do users need to do physically and cognitively to use the system effectively? Is this realistic for the target users?
• How will the interaction unfold over real time and in real space? Does the flow work logistically, as well as conceptually?
• Besides the expected user, who else will participate in the interaction (directly or indirectly)? Does this change anything?

To illustrate how real-world logistics can affect the user experience, here are a few examples from some of our recent usability projects:

1. Mobile Application. We observed users downloading and installing banking software designed for use on smartphones. During installation, users were given a long confirmation number and were told to write it down, as they would need it again later in order to launch the software. Our study participants balked: One noted that if he was on his BlackBerry, that meant he was away from his desk, with no pen and paper in sight.

• Lesson: On a mobile device, it's important to make sure that tasks can be performed with a minimum of additional resources.

2. In-Store Kiosk. Employees at an electronics store were asked to walk through a buy-flow scenario in which they were helping customers subscribe to internet service at an in-store kiosk. Employees' concerns focused less on the UI itself and more on how they would manage customers at the kiosk. For example, how would they minimize congestion and wait time? Which screens should the customer fill out and which screens should the employee fill out? Would they be able to print from the kiosk?

• Lesson: The real-world environment of an in-store kiosk requires complex user scenarios. In spaces where sales associates and customers work together to complete a task, the design should help facilitate this interaction.

3. Web Activation. To activate a new hardware device, users had to complete a web activation that involved entering their device's 12-character identification code. Success depended on users' ability to coordinate action and attention between keyboard, computer monitor, and device. This was a real challenge for many users because they were not touch typists. Many made simple – but extremely frustrating – errors such as failing to click into the field before typing the code, missing a character, or mistaking zeros for ohs.

• Lesson: Whenever tasks simultaneously burden cognitive and motor skills, user errors (and frustration) are likely. In such cases, preventing errors is important but not always possible. Helping users recover quickly and gracefully from errors – e.g., precise error messages, auto-correcting typos – can be vital for a positive user experience.

4. Online Quotes. When requesting an insurance quote online, users were asked detailed questions about their current deductibles and levels of coverage. Most people in the study said they would want to complete the quote form at home, where they would be able to look up their current policy.

• Lesson: When information required to complete a task is not likely to be top-of-mind, tell users up front what will be required and/or allow them to save their work and return to finish it later. This will prevent wasted time, task abandonment, and entry of inaccurate information.

5. Time-Tracking Software. Time-tracking was a component of a larger personal information management suite we tested in the lab and in the field. While very impressed at the program’s ability to automatically associate time spent on the computer with a given project, most study participants' also spent significant time offline – in meetings, phone calls, or out of the office – and they wanted to be able to allocate this time to projects as well.

• Lesson: When a program cannot automatically account for or predict all real-world behavior, allowing simple manual editing or the ability to insert events after the fact is a must-have feature.

These examples give a taste for some of the real-world issues users confront… and designers have to plan for. They also underscore the value of field testing systems in users’ natural environments, where these types of issues will naturally surface. For lab-based usability work, the goal should be to create tasks and scenarios that evoke as much of the richness of the real-life user experience as possible.

• Look for existing models
• Think about tasks, not features
• Don’t assume users will understand your solution
• Talk to those with frequent and direct customer contact
• Beware of analysis paralysis

Look for existing models

The great thing about the web is that with some digging, you can sometimes find solutions to design problems similar to the one you are trying to solve. Of course, competitors are a great resource, but also think in terms of comparable systems. For example, if you are presenting data in a table, a webmail inbox can provide a starting point. If you need to create a step‐by‐step process, ecommerce checkout flows can provide examples of progress indicators and navigation. Most e‐commerce sites also have robust sort and filter controls on pages that display search results for products. We also use the Blink Design Library to capture examples we think are particularly useful.

Think tasks, not features

One of the most common situations we encounter in our consulting work is features that are "tacked on" to existing functionality without considering current task flows. This makes new features less discoverable (sometimes, completely ignored) because they are outside of users’ typical work patterns. This topic probably warrants an essay in and of itself, but suffice it to say it’s important to always step back and ask "how easily will users be able to access this new feature?" If you are relying on documentation or training to do the job, you probably need to re‐think the implementation.

Don’t assume others will understand your solution

Designing can be a humbling experience. You may have come up with what you feel is a compact, elegant solution – and of course you understand how it works because you created it. But putting it in front of other people can quickly illuminate its problems. Even if you don't have time or budget for user testing, asking a colleague for feedback can be invaluable. (This is a major reason we do internal design reviews at Blink before we present our work to clients.)

Talk to those with frequent and direct customer contact

Sometimes, we see clients who have spent considerable resources solving the wrong problem. It usually involves an incomplete understanding of what users want or what barriers they are encountering. If you aren’t able to conduct up‐front user research, consider interviewing internal people who spend their days working with your customers: for example, customer service representatives and sales people usually have a rich and broad perspective on how people actually use a system under real‐world conditions. Often, users find creative ways to use existing features in a manner you may have never considered. Understanding these variations can lead to important insights.

Finally, beware of analysis paralysis

Design problems and solutions can be analyzed ad nauseum. Keep in mind that there are often multiple (and equally appropriate) solutions to any given design problem. This isn't to say you shouldn’t explore various alternatives, especially for more complex problems. But there is a balance to strike and at some point you need to stop analyzing and start designing. Use the methods above to try to evaluate solutions as objectively as possible. It can be difficult, but avoid getting emotionally entrenched in one approach vs. another. Be conscious about when your team’s discussions may be drifting into diminishing returns and it is time to make a decision and move on.

Here are some tips we’ve learned from clients and from our own experiences working within companies to increase the likelihood that: 1) design changes will happen at all, and 2) the changes will be grounded in study findings. It's helpful to think about some of these tips before embarking on a usability testing project.

1) Involve UI owners in the testing. Seeing is believing: Invite key design stakeholders, developers, and business managers to attend usability sessions. When the owners of user interface schedules, priorities, designs, and budgets witness usability problems and barriers first-hand, making the case for changes after a study is much easier. Try to get stakeholders to observe more than one session, and make session recordings available to them after the study. Involve them in reviewing test plans and participant recruiting screeners, and definitely invite them to results presentations.

In some of the more gratifying projects we’ve worked on, UI design and development stakeholders were fully involved in the testing and empowered to act on results, and we were able to work together with them to prioritize problems and create design solutions almost immediately following the testing sessions.

2) Triage and prioritize study findings. Your usability findings and recommendations report may contain issue severity and scope ratings to help you differentiate high-impact issues from relatively minor problems. Work on building team consensus around what the high priority usability issues are and why it is important to fix them. The pay now or pay later rule applies: do not make the mistake of sweeping big issues under the rug and working only on numerous minor, cosmetic problems. Design changes that address widespread, high-severity problems, even if painful to implement, nearly always improve overall product usability more significantly in the long run.

3) Find and empower a user experience champion. We work with these people all the time. They obsess about user experience and usability, bring us in to help them evaluate it objectively, stay up at night designing comprehensive solutions, and then work with their teams to push the right solutions through. (Then they usually test again to make sure they got it right.) These champions can be found at all levels on the organization chart, but they need to have sufficient authority to impact change (or like-minded friends in high places). Effective champions can cross functional or political boundaries in an organization or on a team so that the right resources are applied toward solutions. For example, a technical writer can communicate a method or workaround to users who bother to consult Help or an Info link, but a better solution may be to engage a UI designer or developer to fix a confusing layout or control in the first place.

4) Talk about ROI when you have supporting usability data. Numerous studies and usability experts have demonstrated that fixing usability issues can have a high return on investment. Among other things, usability gains can improve click-through and conversion rates, decrease support costs, and increase customer and brand loyalty. If you have usability data that can be directly or indirectly linked to your company’s ROI, by all means use it to help persuade others that making design changes is a sound idea.

5) Get to know your web analytics team. For web projects, couple usability findings with web metrics. Web metrics may show, for example, where drop-off or abandonment rates are occurring, and usability findings can demonstrate through direct observation of users how usability problems occur within those pages or processes. Linking these sources of information together in a presentation helps make a powerful case about the need for design change.

6) Depending on your development culture, create usability bugs. In some development environments, design changes occur only after bugs are logged in a defect-tracking system. The trick to entering usability bugs is isolating the issues identified in testing into multiple, single bugs and communicating clear steps to resolve each of them. If a problem is complex or the issues are interrelated, resolution steps will need to be hashed over outside of a bug database, but at least entering bugs in the system ensures that usability problems are visible beyond findings reports and presentations.

Enter usability bugs as quickly as you can following testing to keep the momentum going, especially when other development team members can easily recall recently-observed usability problems. A usability lead or champion should be at the table at bug triage meetings so important usability issues and potential design solutions are not deferred to the next release or, worse yet, forever.

Caution: it is not acceptable in some development cultures to enter usability or user experience "bugs." Before doing so, meet with test engineers or other owners of the defect tracking system to see what is culturally acceptable (and/or changeable). The person entering usability bugs must also understand team bug rating or severity-assignment norms that dictate whether an issue even gets looked at during rapid-fire triage meetings.

In cultures where entering usability bugs is not acceptable, consider creating a prioritized list of proposed usability findings-based design changes, the rationale behind each, and then meet with team design/development stakeholders to review them.

7) Press the flesh. You may find yourself in a position of having to sell usability study results and design recommendations to others in your organization. Get out, attend meetings, and speak to key stakeholders and project team members. It can be helpful to create customized versions of usability reports and findings for different audiences. For example, some stakeholders may only skim an executive summary of prioritized issues—make sure it packs a punch.

Establish good relationships and credibility by learning to speak in terms familiar to developers, customer-facing sales and marketing personnel, and other business decision-makers. Make sure the recommended solutions based on usability findings are realistic and actionable, and be careful not to alienate others when pushing for change because you did not take enough time to understand their perspective. In development environments, staying up on industry trends, technologies, and development challenges facing a team helps usability advocates build credibility.

8) Revisit test results between releases when writing new requirements. It's a good idea to dust off usability study findings following a release or iteration. It’s common to find that some, but not all, of the issues identified through usability testing have been addressed. As requirements are being generated for the next development cycle, check progress and make sure design or usability requirements based on previous testing results find a place at the table.

If possible, test more than once and revise prototypes or designs between usability testing milestones. Setting expectations at the onset of a project that proposed design changes will result from each usability study helps ensure that time and resources to specify and implement the changes get baked into project plans. Iterative testing is also one of the most effective ways of ensuring that you are creating usable products.

9) Personify the problems observed in usability findings. Usability studies uniquely draw from the observed experiences of representative users interacting with a product, site, device, or service. There is power in observing people interacting with a system, and the people or customers observed should not get lost in the reporting. Usability reports and presentations are the most impactful, in our opinion, when they illustrate problems via representative video clips of participants, when they contain participant quotes, and when they tell a compelling story about both the strengths and weaknesses of the tested design. Assuming that the right people were recruited for a study, the right tasks were tested, and the problems that study participants faced are accurately and concisely described in the reporting, solutions to the problems can more easily sell themselves.

10) Be candid with your usability consultant about your goals. Usability studies and findings can be tailored to suit specific needs: As you are working with a consultant or internal usability team to scope and design a study, make sure they are aware of any explicit and implicit goals you have for the results. A strong need to “sell” usability and design change within an organization that is new to usability testing may dictate a more formal writing style and tone in the final report, while teams that are old hands at usability testing may prefer a more direct style that gets to actionable results quickly. Let the usability consultant know whether a document or presentation will need to stand on its own and have a life internally or externally after the study.

Why interview?

Interviewing is often preferred over other self-report measures, such as questionnaires, when the goal is to understand issues that are difficult for people to articulate in a concise response (e.g., "How do you define effective teamwork?"). In my experience, verbal responses are typically longer, more spontaneous, and include more specific examples than written ones. The flexibility of the give-and-take interview format allows the researcher to probe more deeply on issues that resonate and follow-up with additional questions to fill in missing details. Interviews are especially useful as a supplement to quantitative measures, such as preference ratings: The "whys" behind ratings are usually much more informative than the ratings themselves.

We typically incorporate some form of interviewing into all of our user studies. In usability studies, pre-session interviews allow us to gather background information about users to provide a frame of reference for interpreting study results, and post-session interviews provide a forum for participants to reflect on the system they just tested. In user research, contextual interviews pair one-on-one interviews with field observations to generate insights about how users function in their natural environments, and what goals, priorities, and perspectives they bring to key tasks.

There are some kinds of issues that interviews are not well suited to capturing. For example, specific usability issues are best documented with detailed observational data, as users are not always able to report on and interpret patterns in their own behavior – for example, they may fail to notice errors or inefficiencies in their actions.

The researcher’s role.

The researcher’s role in an interview goes beyond reading out a list of questions. A thoughtful interviewer:

• Sets the stage. Participants feel more comfortable and provide better information when they understand the focus of the study and how the information they are providing will be used. The researcher should describe the basic goals of the interview, set expectations about what questions will be asked, promise confidentiality of responses, and establish the tone by building a comfortable rapport.
• Gathers all the necessary information: The interview is designed around a set of key research questions, and it is the researcher’s job to ensure that he or she gathers information about all the important topics – rephrasing, repeating questions, and probing further as necessary.
• Gets participants to express themselves fully: Some participants are more articulate and expressive than others, but the goal is always to help each participant find ways to communicate the important details of their experience as fully and clearly as possible. Probing for examples, adjectives, feelings, and asking people to "walk me through" an experience are all good strategies for eliciting detailed accounts. Following-up on non sequiturs, hesitations, and subtle facial expressions can also reveal unexpected, rich content.
• Follows, doesn’t lead. Well-designed interview questions are requests for information (e.g., "Tell me about your experiences with X…"); they don’t lead people to particular responses or put words in their mouths. On the contrary, the researcher should be following the respondent’s lead, taking cues from their mood and language as a way to build trust and shared meaning. For example, I like to repeat back a person’s own words when I ask follow-up questions for clarification or elaboration, – e.g., "You said you’re ‘not really a bells-and-whistles sort of guy.’ Can you say more about that?"
• Respects the participant’s perspective, empathizes: The researcher aligns him- or herself with the participant and communicates genuine concern and interest in what the participant has to say, for better or worse, making the interview a "safe space" to broach sensitive topics, reveal "embarrassing" misconceptions, and speak freely about likes and dislikes. The researcher treats the participant as the expert: Interview questions are legitimate requests to be educated, not demands for information.
• Rolls with the punches: The researcher must balance the need to get key questions answered with the need to let people tell their stories in a natural, spontaneous way. A flexible interview protocol and a conversational style allow the researcher to move smoothly between questions as specific topics arise, to gently redirect off-topic conversation, and still ensure coverage of the important issues.

Identifying and reporting findings.

I think about data analysis as both a "top-down" and a "bottom-up" process. In the standard top-down approach, the study’s original research questions are the starting point. The researcher "interrogates" the interview data for evidence bearing on each key question, typically categorizing participant responses by question. In the bottom-up approach, the raw interview data serve as the starting point. The goal is not to interrogate the data, but rather to listen and receive the messages the data are sending. These messages (or themes) may map on to specific research questions, or they may reflect additional findings that "grow up between the cracks" of the study. Taking both approaches means that key research questions are prioritized while still making room for new questions and issues to emerge.

Good interview data pay off in final reports, where participant quotes and video clips give substance and personality to study findings. Through quotes and video, users speak directly to product teams, in their own voices, about who they are and what they want to see.

Recommended Reading:

Learning from Strangers: The Art and Method of Qualitative Interview Studies
Robert S. Weiss

Discourse Analysis: Theory and Method
James Paul Gee

Incorporating an eye tracker in a usability test gives us more precise information about how discoverable or attention-grabbing visual elements such as navigation structures, screen graphics, links, text, multimedia content, or promotions are to study participants.

Eye-tracking benefits

Eye tracking data can help clients improve and streamline designs. By identifying and understanding individual and common user gaze patterns and eye movements when viewing online content, we can address research questions such as:

• What do users look at first on our home page (or any page, for that matter)?
• Do the calls to action on this page stand out immediately?
• Are users reading this content?
• Are users noticing this interface feature and if so, how long does it take before they look at it?
• Which of these navigation systems is the most discoverable?
• What page elements are distracting users from easily accomplishing this task?
• Will our new design be more effective than the current design?

Eye tracking gives us valuable insights into how users perceive online content. Data generated from eye tracking, when combined with findings from traditional usability methods, can help teams optimize layout and visual design, leading to better user experiences and higher conversion rates. Eye tracking studies can also be a cost-effective way for clients to ensure that they are getting a good design and usability ROI.

How does eye tracking work?

We use an eye tracking system developed in Sweden by Tobii Technology. The Tobii eye tracker looks like a computer monitor (see Figure 1), but sensors are built into the monitor's casing that send and receive reflections of infrared light from study participants' eyes. It is quick and easy to train or calibrate the eye tracker to work with an individual at the start of a usability session, and the technology is completely safe.

Figure 1: Eye tracker built by Tobii Technology.

When users view screen content—a web site, application, image, video, marketing piece, etc.—the eye tracking system precisely tracks and records where their gaze pauses or fixates, even if only for a 10th of a second. The system also tracks and records the eye movements or saccades between the fixation points.

A brief example

For illustrative purposes, we ran a short eye tracking test with a small sample of five users on the web site of one of our favorite charities, Oxfam America. Participants, all unfamiliar with the site, were given the task of finding a way to donate to Oxfam. Figure 2 shows a "heat map" of what our sample of users looked at during their first five seconds on the home page. The bright red-orange spots are the parts of the page users fixated on most frequently. We outlined the two pathways to donate, "What You Can Do" and "Donate now," in red.

Figure 2: An eye tracking "heat map" of the Oxfam America home page showing what test participants viewed most frequently during their first 5 seconds on the site.

Unfortunately, both pathways to donate on the home page received little initial attention. All testers found and clicked one of the links within 16 seconds, so task success was 100%, but if a primary purpose of the Oxfam America site is to collect donations, the call to action on the home page may not be clear enough. It's also possible that a more subtle approach to soliciting donations is more effective for Oxfam's audience—we don't know, and Oxfam is not one of our clients.

While heat maps show how different page elements command visual attention relative to each other and can be generated for individuals or a group of users, gaze plots and gaze replays show the visual path that individual users take on a page. The numbered circles in Figure 3 reflect what one user in our mock study fixated upon first, second, third, etc. during her first two seconds on the Oxfam site.

Figure 3: A gaze plot showing one user's initial eye movements and pauses (or fixations) across the Oxfam America home page.

By analyzing individual gaze plots, we can identify patterns about the order in which study participants view a page or application screen. These patterns can reveal mismatches between where users expect to find links, controls, or content and where they are actually placed on the page, and the patterns help us to recommend changes in the way content or navigational elements are spatially arranged or aligned. For example, a gaze pattern that involves a lot of back and forth movement may suggest a need to place certain items closer together.

One useful feature of the eye tracking system is its ability to track views or fixations in specific areas of interest (AOIs). Once defined in web page or other on-screen content, the eye tracking analysis software can then generate quantitative data such as:

• the percentage of users whose eyes fixate on the AOI
• their gaze duration time within the AOI
• the number of fixations on other page elements prior to viewing the AOI

Figure 4 shows data from an AOI we defined around Oxfam America's "Donate now" box. This chart reveals that 3 users noticed the "Donate now" box, and it took them between 2 and 10 seconds to first fixate on it. Putting on our design hats momentarily, the brown "Donate now" box in Figure 3 looks a lot like a heading and less like a button, which may be why two of our testers did not notice it at all.

Figure 4: "Time to First Fixation" graphic based on the "Donate now" area of interest.

It can be telling how many people simply do not notice an AOI and thus are missing out on an important site function or brand message, echoing the old usability adage "If the user can't find it, the function's not there."

How does eye tracking change how we conduct usability studies?

We do not view eye tracking as a replacement of traditional usability testing methods. With some minor modifications to introduce the eye tracker and fully take advantage of what eye tracking does best, we typically run studies very much as we always have. The data generated from an eye tracker complements other usability findings to give us a more comprehensive and sometimes more quantitative view of usability problems. Eye tracking data can help us pinpoint barriers and distractions that prevent users from finding things quickly or otherwise degrade their online experiences, and it can reveal interesting viewing patterns that lead to better, actionable design recommendations that meet both user needs and business goals—and those are the things we think help our clients the most.

Thanks to Laura Barboza and Jen Amsterlaw for their research assistance.

References

"Eye tracking in human-computer interaction and usability research: Ready to deliver the promises," Jacob, Robert J.K. and Keith S. Karn. Published in "In the Mind's Eye: Cognitive and Applied Aspects of Eye Movement Research," Elsevier Science, Amsterdam (2003)
http://www.cs.tufts.edu/~jacob/papers/ecem.pdf

"A Comparison of Eye Tracking Tools in Usability Testing," DeSantis, Rich, Quan Zhou and Judith A. Ramey. Society of Technical Communication Proceedings (2005).
http://tc.eserver.org/dir/Eye-Tracking

"Tobii Eye Tracking: See through the eyes of the user."
Usability brochure available from http://www.tobii.com

Oxfam America Web Site
http://www.oxfamamerica.org

1. "This should be more like Google." Several sites and applications we tested included home-grown yet sometimes very powerful search features. Google has raised user expectations that all search experiences will be fast, accurate, and relevant, regardless of the platform, site, or application. Study participants are increasingly losing patience with poor search experiences. Requiring users to enter values in separate search fields based on data sources or data requirements is particularly difficult to pull off—users occasionally input terms incorrectly or in the wrong fields yet expect the search tool to "just work." Study participants also expected search tools to "be like Google" by accepting natural language searches, offering "Did you mean?" correction suggestions, and providing concise tips when no results are found.

2. Sub-sites can face an identity crisis. We occasionally test sites that are embedded within a larger company or organizational site. Sub-sites can be fairly autonomous and have their own designers, content producers, and budgets, but may be required to use navigation, templates, and other elements inherited from the parent site. Consistent problems we have observed when testing sub-sites are: 1) users cannot always easily find sub-sites from the parent home page, and 2) users all too easily link away from the sub-site and cannot easily return. Successful techniques to help build awareness and keep users housed within the sub-site experience include:

• using and marketing memorable URLs that create a unique identity for the sub-site (such as www.npr.org/music)
• working with owners of the parent site to improve navigation to the sub-site, and
• optimizing the site-wide Search tool such that certain keywords and synonyms display results that direct users to the sub-site.

3. Information architects of the world: your work is not yet done. Information architecture is as important as it ever was. Good global and local navigation labels make all the difference, as do solid groupings, links placed where people need them, and well-designed content pages. Getting to the right medical care and insurance information was imperative to users of two health-related sites we tested, and in both cases content producers duplicated links to help ensure that information was discoverable. The multiple entry points were problematic, however, as study participants tended to view all links so they would not miss important information. Participants viewing one home page with numerous links could not make quick and accurate decisions because: 1) links were not grouped into meaningful categories and 2) users had to slow down and read through too many choices. Gaze plots from our recent eye-tracking studies also showed users skipping over important items in a too-long list of links or abandoning long lists of links altogether in favor of other page navigation.

4. Profile customization on social networking sites: freeform or controlled? Allowing extensive customization of user profile pages, particularly within two social networking sites we tested last year, proved to be a double-edged sword. Study participants liked the idea of creating their own pages and many of the tools and features that would allow them to do so, but they did not always like the side effects. Some told us that: 1) it feels like work if they have to make too many decisions, and 2) they don’t want to be subjected to bad user experiences when browsing other profiles that are not designed well. It’s great to give users the freedom to create—perhaps up to a point.

5. Keep users in their comfort zones. Keeping users in control of their experience is an important usability principle. This can take many forms, from providing a clear sense of place or progress in a flow to offering "undo" options. We tested a few web sites last year that pushed video or audio content to unsuspecting users as soon as they opened a page. Auto-play distracted users from their primary task or caused them to search for quick exit points. Other sites with multimedia content kept users in control by offering "Listen" or "Watch the video" links and obvious playback controls. Sometimes keeping users in control involves stepping them through complicated processes at their own pace or allowing them to filter and process emotional or sensitive information gradually, enabling them to retreat if overwhelmed. We observed the latter when testing health-related content explaining serious illnesses and procedures.

6. Beware of placing important navigation in visually distinct right margins. We noticed in several web site studies that study participants had difficulty discovering links in right margins that were strongly delineated by line and color differences, especially if these regions also contained photos, graphics, or "spotlight" promotional content. Users in some studies essentially ignored the right margins, which led to task failures if important links had been placed there. Participants later commented: "I assumed that section was advertising" or "I thought that area was just fluff." In contrast, we tested other sites that contained important links on the right-hand side of the page that were highly discoverable. In these cases, the right margin was integrated into the main body of the page—it was not a visually distinct or strongly delineated section.

7. "Help me make a case." Before making purchases, web site users often need to convince other stakeholders at work or in the community, spouses, friends, or even their children. Participants in several of our studies looked for features to formally or informally evaluate, compare, explain, and ultimately share information. This aspect of some sites fell short, judging by comments such as:

• "I can’t find a way to send this"
• "This is way too technical for my manager"
• "This wouldn’t convince my teenagers to come along."

Participants appreciated features such as "Email (or share) this page," technical content revised for sending to less technical audiences, sharable wish-lists, feature and cost comparison tables, user ratings from peers, and other content they could use to persuade others or support group decision-making.

8. Don’t alienate existing users with inconsistent interactions. When we tested an important new feature within a mature product, all of the usability study participants (who were current users) expected to interact with its interface as they do with existing features: they tried to display data via the same sequence of actions and they right-clicked on objects, expecting to see common commands on context menus. These interactions were not present in the iteration of the product we tested, and users struggled to use the new feature, complained about its inconsistency, and said they were not likely to use it. Fortunately, the testing helped the development team recognize how important consistent interaction can be for their users.

9. Discoverability can be a challenge with distributed interfaces. Applications can be distributed in numerous user interface components that have specialized uses and features—consoles, plug-in toolbars, notification area icons and menus, notifications or "toast" messages, sidebar gadgets, web bits, and traditional single or multiple document user interfaces. Breaking applications into components that work on demand in different user contexts can be powerful but can also present discoverability or memorability challenges ("where did I go to do that before?"). A promising new application we tested in a usability field trial last year had user interfaces in at least six distinct places, some of which were highly discoverable and others were not. Some of the "hidden" UI delighted users. Identifying discoverability issues during the field trial helped the team design a first-run product experience that draws attention to some of these less discoverable interfaces.

10. Preference measures can reveal more than numbers in a usability setting. When projects are in an early design phase, we sometimes ask participants to explore concepts or visuals and then rate them or rank their preferences. Preference measures are based on user opinions rather than observed behaviors, but they can help steer projects in the right direction. As participants expressed preferences in studies last year, we observed:

• Concept renderings need to isolate the right variables. Visual or architectural differences in renderings that seem insignificant to designers can be the elements that participants seize upon when rating or ranking things.
• The "whys" behind ratings are often as important as the ratings themselves. The one-on-one usability setting can be especially effective in drawing out the deeper reasons and opinions behind the numbers.
• While participants often report difficulty rating concepts without seeing how they will be implemented, they can be a rich source of information, suggesting features, requirements, or other attributes that had not been considered previously.
]]> http://feedproxy.google.com/~r/blinkessays/~3/ro3otXZ8Wjc/usability_highlights_2007.php http://www.blinkinteractive.com/essays/usability_highlights_2007.php Blink Interactive Wed, 06 Feb 2008 18:29:22 +0000 http://www.blinkinteractive.com/essays/usability_highlights_2007.php This past June, I attended the Usability Professional Association conference—the theme for which was Patterns: Blueprints for Usability. It provided the opportunity to hear a number of different perspectives on user interface patterns—and I presented my own thoughts on the topic as a conference presenter.

My relationship with user interface patterns goes back to the year 2000, when I was developing the topic for my master’s thesis. The research I did—examining 75 leading e-commerce sites for design similarities—was closely related to the idea of patterns. However, for a number of reasons, I did not structure the research as patterns. The main reason was that my research focus was identifying the range of solutions to a given design problem. Patterns seemed more suited to documenting (in great detail) idealized or archetypical solutions.

The promise of patterns is alluring—the idea that you can solve a particular design problem by looking up the solution in a pattern library. In theory, designers use a pattern library to document user interface solutions, which are subsequently re-used by other designers. The very detailed, structured pattern description provides complete information about what the pattern is, when to use it, and why it works. There are a number of pattern libraries available on the web including welie.com, the Yahoo pattern library, and Designing Interfaces.

Despite the promise of patterns, as a working designer I have found the practical usefulness of patterns limited. One problem stems from the "look up" model of use that patterns assume. If I am grappling with a design problem and want to look up the solution in a pattern library, I need to know how to find what I’m looking for. For simple, well-known problems I can probably take a good guess at the name of the pattern and look it up that way. But of course if it’s a simple, well-known problem I’m probably not grappling with it in the first place. For complex or unique problems—the types of problems experienced designers do grapple with—it can be very difficult to pin a label on the problem that you are trying to solve. In my experience, time is usually better spent working to solve the problem than navigating through a pattern library in search of a ready-made solution.

However, I don’t discount the idea of documenting and analyzing user interface solutions. In fact, I advocate quite the opposite. The research I did for my master’s thesis convinced me of the value of spending time understanding others’ design solutions. The difference is I advocate documenting design solutions primarily for your own use—not as a resource for others to draw on. What I recommend is creating and maintaining a personal design library.

The personal design library contains design examples that are particularly useful to you. What you may find useful could vary based on the type of design work you do and your level of experience (junior vs. more senior). For example, I wouldn’t collect an example of global navigation with "flyout" submenus, because this is a solution I am well-acquainted with. However, I did collect the example below, which shows an interesting variation on this type of navigation. (The flyout displays a few top options with a link to the entire set of options—particularly handy when the amount of sub-options is large.)



I don’t describe the solution using the structure of a pattern, which, with its prescriptive categories, can be intimidating (and time-intensive) to complete. Instead, I use a more conversational style, explaining why I captured the example and my analysis of it (both good and bad). Bad examples can be particularly illuminating. For example, if something in a system trips me up, I’ll stop, take a capture of it, and then think through why the design was a problem for me. (I have also collected examples from usability studies I have conducted.) The key is to keep the documentation for each example brief and concise. This makes it easier to maintain your design library and maximizes the chances you’ll actually keep it up to date.

The Blink Design Library is an example of a personal design library, which is publicly accessible. We chose to use make it public so others could see how ours is set up to start their own. To create ours we used blogging software that supports tagging (categorization) of posts. A flat vs. hierarchical categorization scheme is another way to simplify the process of documenting examples.

In short, developing a personal design library can have a very high return on the time invested: you will improve your design skills by systematically examining solutions—both good and bad. While user interface patterns all share a worthy goal—to document solutions in a way they can be re-used by others—practicing designers will likely find a personal design library a more effective avenue to building design skills.

]]> http://feedproxy.google.com/~r/blinkessays/~3/_lnSAasfC8U/interface_patterns.php http://www.blinkinteractive.com/essays/interface_patterns.php Blink Interactive Tue, 06 Nov 2007 18:43:23 +0000 http://www.blinkinteractive.com/essays/interface_patterns.php Seniors are increasingly using the web to shop, find news and information, and connect with friends and family. But many websites are not designed with seniors in mind. You can make your website more senior-friendly by following a few simple rules of thumb… and the end result is often improved usability for users of all ages.

In 2007, surveys conducted by the Pew Research Center found that 32% of Americans aged 65 and over are using the internet. This number will skyrocket over the next 10 years as a wave of technophile Baby Boomers - the so-called "Silver Tsunami" - attains senior status. Seniors can be especially enthusiastic internet users. However, designing websites that seniors enjoy using requires taking into account seniors’ unique usability requirements.

Today's seniors have unique website usability requirements for three main reasons:

1. Physical changes associated with aging
2. Generational differences in computer experience
3. Use of older computer technologies

Physical Changes Associated with Aging

As we age, we experience changes in eyesight, motor control, and memory. All of these changes have implications for how we interact with computer interfaces. For example, due to changing eyesight, many seniors experience difficulty when websites contain text that is small or has limited white space. Changes in motor control result in less precise use of the mouse; thus, seniors also require larger targets for clicking and do better with static interface elements.

Recommendations:

• To improve readability, use high-contrast text and background colors. Use a larger font size (at least 12 pt) or ensure that your site is set up to allow users to increase the text size as desired. In addition to page text, ensure that important hyperlinks, commands, and logos are large or can be resized.
• Use more white space between lines of text. This is especially critical for hyperlinks and command buttons. Using more white space improves readability and also reduces the number of erroneous clicks due to less precise control of the mouse.
• Avoid long pull-down menus or fly-out menus. Large, static interface elements are easier targets for clicking
• For clickable elements, require single-clicks, not double-clicks. Double-clicks can be difficult for users with more limited motor control.
• Older users can have more difficulty recalling their path through a website and remembering what links on a page they have already visited. Use sequence maps or breadcrumbs so users can easily see where they are. Clearly distinguish between visited and unvisited links.

Generational Differences in Computer Experience

Many of today's seniors retired from the workforce before computers and the internet became the workplace staples they are now. As a result, their experience – and comfort level – with computers and the internet is more limited than that of recent generations. Older users are often unfamiliar with specialized computer terminology, as well as web design conventions that more practiced users find intuitive. (For example, in a recent usability study conducted here at Blink, roughly 80% of participants aged 48-66 years old were unfamiliar with the practice of clicking on the company logo as a way to return to the homepage.) Seniors who don’t feel confident about their computer skills may also be worried about "making mistakes." They can be overly cautious when exploring new websites and may be reluctant to click on links and commands whose functions they are uncertain about. Due to security concerns, they may be especially wary of websites that ask them to download software, register their email addresses, or provide other personal information.

Recommendations:

• Use clear and simple language throughout your website. Avoid overly technical information and jargon. Jargon-heavy error messages and "fine print" can be especially confusing and intimidating to novice users.
• Label buttons, important links, and other key interface elements with straightforward descriptive labels such as "Home" and "Search." Some older users will be unfamiliar with even the most basic web design conventions. If page space is an issue, consider using roll-over "tool tips" to explain objects' functions.
• Make sure that forms and instructions are "supportive and forgiving," allowing users to enter information in a way that is natural to them. One example of a forgiving design is allowing credit card numbers and phone numbers to be entered with or without hyphens
• Encourage exploration by making it safe to explore. Include "escape hatches" that allow users to cancel, undo, or back-pedal if they find that they have made a mistake, followed the wrong link, or just want to start over.
• Make it easy for users to get help. Include obvious links to help pages and company contact information. Always include a phone number: Many older users prefer to talk with a real person about their questions and concerns.

Use of Older Computer Technologies

Computer hardware, software, and internet capabilities are constantly changing, enabling ever faster, more complex, and more interactive website functionality. But many older users are not keeping pace with these changes. For example, data from the Pew Research Center indicates that in 2007, roughly 85% of users over age 65 are still using dial-up to access the internet. Older users are also much more likely to be using older computers with less powerful processors and lower-resolution monitors, running older internet browsing software, and relying on “bare bones” hardware devices, such as mice that lack scroll wheels.

Recommendations:

• Plan your website testing to include hardware, software, and connectivity configurations that will mimic an older user’s experience. Ensure that key aspects of the user experience are functional and responsive under less-than-ideal circumstances.
• Widen page margins so that your website can be viewed successfully on monitors with lower screen resolution and narrower aspect ratios. A margin of 1.5 inches or greater is recommended.
• As much as possible, minimize the need for extensive scrolling. Too much scrolling is already a pain point for many users; it is even more so for users whose mice lack the convenience of a scroll wheel. Increasing text size often results in a longer page, and finding ways to maximize text while minimizing scrolling can be tricky. One solution is to break longer pages up into sections and allow users to jump from section to section via forward links placed at the end of each section.
• Be aware of the processing and connectivity demands your site makes on users who lack state-of-the-art machines and high-speed internet connections. If appropriate, offer different versions of your site based on a user’s connectivity, and consider giving users control over what page elements load automatically (e.g., text only, text and images).

Seniors overwhelmingly prefer websites they find easy to use. It isn’t surprising to learn that most other user groups feel the same way. This explains why usability studies often find an added benefit of making websites more senior-friendly: It makes them easier for everyone else to use as well.

References:

"Making your Website Senior-Friendly" (NIH)
http://www.nlm.nih.gov/pubs/staffpubs/od/ocpl/agingchecklist.html

"Older, Wiser, Wired" (AARP)
http://www.aarp.org/olderwiserwired/

"Seniors and the Internet" (Pew Internet and American Life Project)
http://www.pewinternet.org/PPF/r/83/presentation_display.asp

]]> http://feedproxy.google.com/~r/blinkessays/~3/nhopeXSmEos/understanding_older_users.php http://www.blinkinteractive.com/essays/understanding_older_users.php Blink Interactive Wed, 19 Sep 2007 21:45:08 +0000 http://www.blinkinteractive.com/essays/understanding_older_users.php A couple of months ago, I was part of a panel discussion on "Real-World User-Centered Design." The topic was the outgrowth of questions from a more introductory forum on user-centered design (UCD) principles. After the introductory forum there were still many burning questions—specifically, how do you adopt and adapt UCD principles to real-world organizational constraints? It's a question we sometimes encounter in our consulting work. To get the ball rolling, we recommend three steps…
1. Understand the basic principles in user-centered design
2. Assess your organization's starting point
3. Use your starting point to strategize next steps

Step 1: Understand the basic principles in user-centered design

At Blink our user-centered design process includes three main elements:

• Conducting user research to drive creation of behavioral profiles and scenarios
• Using behavioral profiles and scenarios to guide our design work
• Prototyping and designing iteratively (testing early and often)

It's important to understand the "pure" process before thinking about how it might best fit into your organization (a good primer is available at IBM's Ease of Use Site http://www-03.ibm.com/easy/page/570). Taking seminars and classes is one of the best ways to learn about user-centered design because you can often get a broader perspective from group discussion. There is a wide range in how organizations implement and practice user-centered design. There is no one-size-fits-all solution.

Step 2: Assess your organization's starting point

To help organizations think about their starting point, I created a model with two dimensions, with the first being how well your product is currently meeting user needs. Is your service center swamped with complaints? Or are you having trouble keeping up with all the complimentary emails and phone calls? The state of your current product governs the urgency to act. A company with a clearly failing product needs to respond differently than one that is basically serviceable, but could be improved.

The second dimension is to what extent you have implemented user-centered design processes. This is at least a partial indicator of how ready your organization may be culturally to move forward in its adoption of UCD principles.

Here's a visual representation of the model; the idealized UCD state is in the upper-right corner.



Step 3: Use Your Starting Point to Strategize Next Steps

In our work with clients, we encounter various organizational starting points. I've plotted three representative starting points on the graph below. These are discussed in the following sections, along with some suggested next steps to move up the UCD curve.



Starting Point: Product Chaos

Occasionally in a client engagement, we step into product chaos. In one memorable case, the client had their product in a trial with a major customer; the trial was in jeopardy because people were not able to perform the system's most basic tasks.

There was high urgency to act, but we felt it was critical to begin with baseline usability testing for two reasons: First, it was necessary to observe why problems were occurring first-hand. Problems reports were mostly second- and third-hand and everyone seemed to have their own ideas on the "silver bullet" that would solve the problems. Second, it was important for the people responsible for creating the user experience (in this case, the engineers) to watch how actual users approached the task.

For an organization that hasn't historically tested their systems, observing a usability session can be enlightening. Sometimes people fear introducing real-users to engineers or other stakeholders: what if the observers rationalize and just think the participants are dumb? This can happen, but honestly in our experience it really is the exception rather than the rule. Two strategies can help forestall this reaction: first, is recruiting to match a profile that users agree is representative. Second, is encouraging viewing as many sessions as possible. It's harder to argue that all the participants are simply incapable.

Conducting baseline usability testing can be an effective “foot-in-the-door” for UCD processes. Once this foothold is established it's usually possible to pursue the next logical step: testing well before a product's release to catch problems before they go out the door.

Starting Point: Usability Awareness

A situation we more commonly encounter is an organization that is conducting usability testing, but only at the very end of the product cycle, when it's too late to incorporate much in the way of changes. Issued are identified—and may be eventually fixed—but known usability problems (sometimes major problems) go out with the release. The organization has some awareness that testing for usability is important but is otherwise not practicing methods that will fundamentally improve how their products are developed.

A next step in this situation is to move towards testing early-stage prototypes. It pushes the timeframe of testing earlier, when problems are easier and less expensive to fix. And while the benefits of prototyping testing are often (rightfully) promoted as a way to catch usability problems, in our experience it also helps prevent another type of problem that can lead to product delays: misunderstood requirements.

In our work with clients, we work from a variety of requirements sources. But regardless of the source, we frequently find that once we start creating a paper prototype based on the stated requirements, somebody has a moment when they realize that the requirements hadn't really captured their intentions. Or, once they look at the prototype, they realize that what seemed like a good idea when described verbally is less so when seen visually. The key here again is catching the problem early, when changes are easier to make.

Starting Point: Proto-UCD

Baseline usability testing, and, better yet, early prototype testing, are great first steps in moving towards user-centered design. But these methods are largely reactive—meaning they are really done after a substantial amount of design work is complete (rather than driving the design).

Organizations that have taken the next step towards user-centered design typically delve into creating personas and scenarios, which are designed to guide design at the very earliest stages in the process. What we sometimes encounter is that these efforts are not based on up-front user research, but instead are more speculative—introducing the risk that they do not represent true user goals and motivations. Often this occurs because the project budget and/or timeframe do not allow for user research. Still, the artifacts are produced, which can lead to a false confidence about how well the system design will meet users' needs.

Doing research with user proxies is a way to get moving towards user research without the cost, time, and effort of field studies. Realistically, it's not always possible to directly observe users for every project. When we are faced with this situation, we try to at least conduct research with user proxies (reasonable stand-ins for actual users). This includes people on the front-lines with customers such as sales people and customer service personnel. The key here is conducting research with people who have direct and frequent user contact (in general non-management personnel). Hopefully, proxy research leads into actual user research. But if not, proxy research can still lead to valuable insights that might not otherwise be uncovered.

Keeping realistic expectations

In improving your organization's UCD processes, it's helpful to think of your efforts as organizational change. In general, implementing organizational change is 20% technical (defining new processes) and 80% social (getting everyone on-board with the change, which may be viewed as threatening). It's important to understand that depending on your organization, process change may take time—and require baby steps that are suited to your particular organizational culture and starting point.

]]> http://feedproxy.google.com/~r/blinkessays/~3/HmFVaEQvrv4/realworld_usercentered_design.php http://www.blinkinteractive.com/essays/realworld_usercentered_design.php Blink Interactive Wed, 01 Aug 2007 20:59:16 +0000 http://www.blinkinteractive.com/essays/realworld_usercentered_design.php Consistency in an interface is generally a good idea, but like many good things, it can be taken too far. Particularly in content-heavy web sites, pages with an overly similar look can make it difficult for users to get a sense of place. Too much similarity can also give a system an overall static feel. The key is to understand when a lack of consistency interferes with the user experience—and when it doesn't.

We've found that for any system type, it's critical that terminology be consistent. Users tend to take terminology at face-value, meaning that when they see different terms they assume each means something different. Or—if the terms are very close semantically and appear on the same page or screen—users will stall and evaluate: which should I choose? On the web, a common example is a page with two or more calls to action: each leads to the same destination, yet they are labeled differently. This is shown in the example below where the two links and the button lead to the same registration page:



Inconsistent terminology can be a big source of usability problems. And it's a problem we commonly encounter: usually it's because different teams work on different areas of a system, with each team using their own set of terms. In theory, inconsistent terminology is a low-hanging-fruit type of item to fix. In practice, because of organizational issues, it can be an uphill battle to get an agreed-upon, centralized set of terms. At Blink, we use Objects and Actions Analysis to identify the important concepts and assign appropriate terms. But even developing a simple alphabetized list of preferred terms can work to keep major terminology conflicts from cropping up.

While it's important to establish basic navigational conventions, page-specific navigation is an area where consistency can be taken too far and actually make a system more difficult to use. The reason is that different areas of a site can have different information structures: one section may have narrow and deep hierarchy, while another may be broad but shallow. There are also different navigation requirements for areas that involve non-linear browsing, those that involve step-by-step (wizard) functions, and those that are search-based. As long as the navigation approach in each instance is clear and does a good job of supporting expected actions, users normally adapt (after all, users regularly encounter different navigation schemes when moving between sites on the web). This is not, however, a carte blanche for navigational chaos. Every attempt should be made to make the scheme as consistent as possible. Striving for navigational consistency is important not only for your users, but for your development team as well. The rules governing navigation should be simple and clearly articulated so that they can easily be followed. One double-check we use in our design work is if we are having trouble communicating the navigation scheme to the client, we need to go back to the drawing board and simplify.

Related to the navigational scheme is the issue of page layout. Sometimes, the navigational scheme drives the page layout; in other cases, page layout requirements drive the navigation. The latter occurs most commonly with promotion-centric web pages, where the goal is to highlight key content and one or two clear calls to action. Many e-commerce sites now use promotion-centric layouts for top-level product category pages, and a more navigation-focused layout for lower-level pages designed for product browsing. And, finally, product detail pages typically have their own unique layout requirements designed to help "close" the sale.

Though we work primarily with grayscale wireframes, we coordinate closely with visual designers to help bring the design into its full-color visual treatment. Here, a common question is about link color: should there be a single link color or different links colors for different areas of a page or for different link types? It's easier on everyone—your development team and your users—if you can stick to a single link treatment. But, again, we've found users contend fine with some variability here as long as the link treatment clearly communicates that the text is clickable. When links appear in a clearly defined navigation area, such as a navigation bar, users assume that the text is clickable—underlining links is not normally necessary. However, we recommend that links embedded in text do have underlining to more clearly distinguish them from non-clickable (plain) text.

Consistent button treatment is also important. In our wireframes we represent three main button types: primary action (represented by a boldly outlined button), secondary actions (using a button with less visual weight), and tertiary actions (a smaller button with the least visual weight). The goal with these button treatments is to clearly and consistently communicate the hierarchy of actions.

Occasionally, we design pages that by their nature have very similar layouts and navigation schemes. The risk here is a lack of feedback—users navigating between these pages may not perceive a difference and incorrectly assume that they are "not going anywhere." In these situations, we recommend visual treatments such as icons and imagery to provide more obvious feedback. It is also helpful to provide clear location indicators: for example, highlighting the current location on a navigation bar. Sometimes, however, this isn't enough. Users tend to focus their attention on the main body of the page and may overlook more subtle changes that occur in the page perimeter.

Overall, our approach is to be consistent where ever possible, but not to force consistency where it doesn't make sense. Our priority is on making sure we use terminology consistently and to develop a clear but flexible navigation scheme. We work closely with visual designers to be sure that where ever necessary consistency is reinforced and differences are appropriately highlighted.

]]> http://feedproxy.google.com/~r/blinkessays/~3/5rw3oLzfze8/consistency.php http://www.blinkinteractive.com/essays/consistency.php Blink Interactive Wed, 13 Jun 2007 18:31:53 +0000 http://www.blinkinteractive.com/essays/consistency.php At Blink, we are sometimes hired to create a conceptual prototype for a product that is in the very early requirements stage. Usually, the product does not yet have internal funding for development and one goal of the prototype is to secure that funding. The prototype may also be shown to trusted customers to get their feedback on the concept.

Conceptual prototypes are often very interesting projects because the ideas are leading edge. But they also present some unique challenges compared to more traditional projects where we are designing for actual implementation.

The first challenge is that the idea for the system may only be a glimmer in somebody's eye. The usual questions we ask up-front in a project to help understand the purpose of the system may not yet have answers. The answers to key questions may be a flat "we don't know" or "it could be x, but it might be y."

As a result of this ambiguity, our discovery phase can turn into more of a treasure hunt, assembling and reconciling the scraps of information that are available. The resulting picture of the system is usually incomplete, with conflicts and missing pieces.

To help flesh out a vision of the system, we often put the information we do have into a mind map.



If you're not familiar with mind mapping, it's a handy way to visualize ideas and the connections between them for all sorts of contexts. There are a number of good mind-mapping software packages out there.

With the mind map created, we begin drafting one or more key scenarios that the prototype will demonstrate. These are often highly speculative - meaning where there are gaps, we just take an educated guess on how that gap might be filled. Even if it's a wild guess, we have found that taking a guess gives something for people to shoot holes in and serves as a catalyst for discussion.

Scenario development and refinement for conceptual prototypes can be a lengthy process because it's coinciding with the process of defining the product. You also need to consider the audience for the conceptual prototype: internal decision-makers may have different questions and concerns than potential customers for the product.

With the scenarios "finalized" we begin to do a black-and-white paper prototype (wireframes) of the demo. I put finalized in quotes because once people see the implications of a scenario illustrated in wireframes, additional problems and questions almost always arise. Any design project is iterative—demo projects are almost always more so.

Assuming a final set of wireframes is complete, the next question is the right format for the final prototype. Here, you need to consider the audience for the product demonstration, who will be giving the demonstration, and the context in which it will be shown. Time and budget of course factor in as well.

The least expensive—and in some ways the lowest risk option—is to simply do an on-screen step through of the black-and-white paper prototype. The risk you mitigate by going with a clearly unfinished-looking prototype is the misperception that the prototype represents a finalized (and possibly fully-functional) interface. However, a black-and-white prototype is not very compelling visually. It may not engage the audience in the product's potential in the same way as full color and partially interactive prototype.

Particularly when creating a more polished, interactive prototype, we include the text of the scenario so that it can be accessed if necessary. This serves as a script someone can follow if they lose their train of thought or are less familiar with the demo.

The expected outcome for a conceptual prototype project is of course, the finished prototype. The unexpected outcome can include a clearer, more cohesive vision of the product through the process of early-stage scenario development and wireframing.

]]> http://feedproxy.google.com/~r/blinkessays/~3/Tzsp0gPuO90/conceptual_prototypes.php http://www.blinkinteractive.com/essays/conceptual_prototypes.php Blink Interactive Tue, 24 Apr 2007 13:50:56 +0000 http://www.blinkinteractive.com/essays/conceptual_prototypes.php In the game World of Warcraft, there is an interesting phenomenon occurring involving participatory design of the user interface.

World of Warcraft (www.worldofwarcraft.com) is described on their website as "a massively multiplayer online game…enabling thousands of players to come together online and battle against the world and each other." Also known as a highly addictive, immersive, and social experience, World of Warcraft is a remarkable game on many levels. However, what is interesting to us at Blink is the way that Blizzard, the creators of the game, made the user interface framework extensible and open, allowing its users to have complete control over the way the game’s user interface is used and manipulated. The game allows support for modifications or "mods" to the game, allowing a fully customizable user interface.

The game is played many ways depending on which "class" a player selects to be, such as a warrior, mage, priest, etc. Each class requires a different skill-set and responsibilities. Furthermore, the player's experience is also different depending on which "profession" the player selects (for example: jewelry making, leatherworking, or mining). Each player has a unique skill set which has engendered specific interaction requirements. For example, while in a group, the priest’s responsibility is to heal his or her group mates. This requires attention to the health bars of other players. Meanwhile, the warrior is more focused on maintaining the attention of the creatures, making sure they do not attack the less melee-inclined players. The following image is a screenshot of the default user interface that is included in the game.



The following screenshot is an example of the user interface after it has been modified.



Note the increase in user interface elements and difference in the layout between the two screenshots. As the players become more skilled and specialized, they require different information and interactions. It is common for players to change the way input is provided such as modifying the key bindings and toolbars. They can also change the type of information displayed with context sensitive functionality. For example, if a particular spell wears off, a player might have a message notifying them to recast it. Another area of modification is automation which can mitigate repetitive tasks or provide a seamless task flow.

Modifying games is not a new phenomenon. The popular first person shooter game Counter Strike is actually a modification of the game Half-Life. While modifying a game engine requires a high level of programming expertise, Blizzard has made the UI framework accessible by using XML and LUA, a very basic scripting language. That is not to say programming isn’t required, but it is certainly more accessible than C/C++ and hacking source code.

What’s also interesting to us is the way Blizzard has responded to the player-created mods. Blizzard has implemented a robust forum on their website where Blizzard employees moderate and answer questions. There are many threads specifically about user interface development where players can showcase their user interface mods. After gathering feedback from the forums, the most popular and deemed useful mods are later incorporated into the default set up for all players to use. Blizzard is cognizant of the fact that no matter how good, intuitive, and useful their user interface is—it will not cater to everyone, particularly the expert players. People spend an incredible amount of time playing this game; so much so, the players know what they need more than their creators ever could. Blizzard is tapping into that rich resource. Even across the same classes of players, many have preferences for different mods.

An example of an application that could possibly benefit from this type of participatory design is Adobe Photoshop. The Photoshop user-base has a diverse spread of expert users that indubitably have insight into what tools would work best for them or what interactions could possibly be missing. Adobe has developed a software development kit (SDK) for Photoshop. However, it is not very accessible to the average or even most advanced Photoshop user. Third party developers have created a plethora of plug-ins and filters but usually sell them due to the skill and time needed to create them.

Photoshop is used for a myriad of reasons—from photo manipulation to digital painting, therefore user interface requirements vary from user to user. There are very few, if any, plug-ins that rearrange the user interface to accommodate any particular user group. It is also impossible for third party developers to be aware of all user needs, so by utilizing grassroots user interfaces, Photoshop could better accommodate the work flow of more end users.

Another example of applications where it would be impossible for developers to be aware of all users needs is CAD programs such as AutoCAD. CAD applications are again used by a diverse set of users, such as mechanical engineers and architects.

By creating a user interface framework and a system for collecting feedback, software development companies can create an environment for communication between their users and gain insight into their interaction needs, creating a great user experience.

]]> http://feedproxy.google.com/~r/blinkessays/~3/SzwEgFjcaXI/world_of_warcraft.php http://www.blinkinteractive.com/essays/world_of_warcraft.php Blink Interactive Sun, 08 Apr 2007 14:32:30 +0000 http://www.blinkinteractive.com/essays/world_of_warcraft.php