Posts Tagged 'usability'

Writing User Help for Older Users

Facebook’s users are getting older. A recent report found an 80% increase in users over age 55. The effects of this change are reverberating, and it’s not just that teenagers are fleeing Facebook like rats off an aging ship. This older demographic may require different approaches to user help. And that’s why the internet has seen a rise in videos like this one helping seniors adjust to the site:

Facebook isn’t alone. The number of older computer users is growing dramatically. In response, companies like HP have designed technology specifically for older users. And several businesses and non-profits, including one founded by this enterprising San Francisco teen, devote their time to helping seniors learn and use technology.

Gail Lippincott argues that “Technical communicators can play a crucial role in meeting the needs of this growing audience of aging adults by acting as user advocates for accessible documentation and interface design.” This requires understanding how older users might approach and use instructions. Considering research that older users are much more likely to reference a manual, this understanding becomes even more important. While many researchers caution against stereotyping all seniors, they have also uncovered some general tips for writing manuals catered to older users:

  • Consider Formatting: While many seniors are in terrific physical health, others need formatting accommodations to improve a manual’s usability. Larger type, easily-turned pages, and fewer distracting elements can help many users. Demiris, Finkelstein, and Speedie provide several recommendations for accommodating elderly users in web design, and many of their suggestions–such as limiting colors, providing several methods for completing tasks, and providing several ways of getting assistance–apply to user help as well, especially when it’s online. W3Schools also provides accessibility guidelines for older users.
  • Increase User Confidence and Motivation: Older users may assume that they just won’t get new technologies. While watching older people use digital products, researchers Abdusselam Cifter and Hua Dong observed that many weren’t motivated to complete the task and blamed themselves for the failure. Manuals that provide extra cues to increase motivation and confidence can help. Nicole Loorbach, Joyce Karreman, and Michael Steehouder found that adding “confidence” elements to a manual increased the number of tasks users could complete and improved their persistence when facing a difficult task. In the study, confidence elements included a section labeled “No prior knowledge of skills required” to convince users that they, like millions before them, could master the task. The manual also offered strategies for reading the manual and included steps helping users check the success of their work.
  • Provide More Context: Older users may need context that younger users take for granted, such as the purposes of technologies and particular tasks. Patricia Robinson writes, “Older users may not automatically fill in missing information that is obvious to younger users,” partially because their thinking patterns are based on “older technological models.” Technical communicators may need to provide additional information or explain metaphors and processes that might be confusing.
  • Involve the Audience: There’s no better to meet users’ needs than to get them involved. Consulting with seniors and testing documentation with them can only improve the product. Plus, it helps companies avoid patronizing older users by creating user help with titles like “Manual for Seniors Scared of Technology!”

As the blog Workplace Writing argues, businesses can’t afford to ignore seniors. And if they can’t get good help using new technologies, they won’t use them.

Advertisement

Employees Know About Usability Than We Think

In Usability Testing Essentials: Ready, Set,… Test!, Carol Barnum lists several great sources for internal information about users:

  • Technical Support/Customer Support
  • Training for Internal/Customer Use
  • Technical Communicators
  • Sales and Field Support

All these sources are helpful, but a recent experience convinced me that an even wider group of employees may posses powerful, but overlooked, usability information.

I placed an order for pictures on the Walgreens website, but when I arrived an hour later to pick them up, they weren’t ready.

“The order wasn’t placed,” the photo clerk informed me.

“But I placed an order,” I responded.

“You have to submit the order. A lot of people don’t notice that,” he responded.

And when I looked at the site again, he was (not surprisingly) right. I had missed a “submit” button at the bottom of a “Review and Submit Your Order” screen. Maybe the employee was just trying to make me feel better, but from the sound of it, he often encounters customers who make the same mistake. Here in my local Walgreens sits an employee with valuable usability insight worth time and effort to customers and money to Walgreens. Presumably, some of the customers who forget to submit will not repeat the order later. Also, they take up time when customer lines are long and frustrate already overworked employees.

While it’s unrealistic to expect companies to survey every employee for usability insight, it’s equally realistic than many of the on-the-ground, lower-level employees possess a wealth of usability expertise about their company’s products (and this includes employees beyond the Sales and Field Support that Barnum lists). The ultimate solution is finding efficient ways to gather to this insight and providing motivation to employees to share their knowledge. But the first step is for usability professionals to recognize that employees possess this knowledge is the first place.

 

Thinking about Iterative Usability Testing as Revising

Last week, while preparing to give a presentation to a group of students, I encountered a problem. When I logged into my favorite online presentation editor, I discovered that the interface had changed almost completely.  There were unrecognizable menus across the top of the screen, and the buttons and menus I was used to were no longer there. I experienced a brief moment of panic. I had to present the next day: how was I going to learn a completely new interface AND complete a presentation visual in less than twenty-four hours? Fortunately for me, a banner appeared at the top of the screen offering me the option to switch back to the “classic” version, at least temporarily. I could create the presentation I needed using the version I already knew and come back later when I had more time to learn the new interface. Not every user is so lucky when it comes to other software or websites.

My potential panic could have been prevented if the developers of the online presentation software had utilized the concept of iterative usability testing. Dr. Jeff Bacha, a professor of technical communication at the University of Alabama in Birmingham, gave a lecture this week at the University of Alabama in Huntsville advocating “In-context” usability studies, and he touched briefly on iterative usability testing as a method of producing more efficient products–and subsequently happier users.

What exactly is iterative usability testing? Iterative usability testing differs slightly from traditional usability testing. In traditional usability testing, usability experts observe users as the users interact with the product after it has been completed or nearly completed. In iterative usability testing, users are offered the chance to evaluate the product throughout its development. In other words, as small changes are made to the product (the software, website, etc.), users are asked to evaluate the product and the specific changes that have been made. When I think about iterative usability testing, I like to compare it to the writing process. To adopt a writing term that many people may be familiar with, iterative usability testing is, essentially, revising. When we write a document, we draft, ask readers for feedback, make changes, and ask for feedback again. We may go through the process half a dozen times or more, producing slightly different–and hopefully improved–drafts each time. Iterative usability testing is a similar process undertaken for a product such as software or a website. The developer makes small changes to a software program or website, asks users for feedback, and takes their concerns into account when making changes to the next version.

In the diagram below, I illustrate the similarities between the two processes. The first stage of both processes is the creation of an initial version of the document or product, a “first draft,” as it were. In the second stage, the product is tested by users (or the document is read by readers) and feedback is collected. In the third stage, that feedback is incorporated into the document or product. In other words, the product or document is revised in order to reflect user/reader concerns. This results in the fourth stage of the document, the new “draft.” I do not say the final draft, because in writing and in iterative usability testing alike, each draft is sent again to readers and users for additional feedback, for as many “revising loops” as time and resources allow before a final version is produced.

The key to successful iterative usability testing is incremental change: if the changes to the product are too drastic, users may be overwhelmed and become unable to point out specific, fixable issues. Take the case of my interaction with the online presentation editor as an example. If the developers had not offered me the alternative to revert to the previous version of the controls, I would have quickly become frustrated, because I didn’t have time to spend on learning the new system right then. In all likelihood, I would have abandoned the editor altogether and gone back to a familiar system like PowerPoint, at least for the project at hand. On the other hand, if, instead of changing the interface all at once, the developers had changed things little by little, asking me along the way (through email surveys or on-site polls) which changes I liked and which ones I didn’t, my potential for frustration would have been greatly reduced.

Iterative usability testing, then, is useful in one respect because it prevents user frustration. However, it is also useful for developers; in the long run, it can save time. Incremental usability testing provides developers with user feedback throughout the development process so that they can tailor the product to the user’s needs. Finding out which features users actually use and which ones they dislike can direct the development process more efficiently. The developers won’t waste time making major changes that users neither need nor want.

Thinking of iterative usability testing in the same way writers think about revising could help developers prioritize their incremental changes. There’s no need to waste time working on an introduction to a document if readers think the draft is fine as it is; instead, the developer can focus on problem areas that will actually improve the reader’s experience. Likewise, there’s no need to work on changing the appearance of the forum on a website if user input shows that nobody actually wants to use the forum.

If the developers of the online presentation editor I was using had asked me, I would have told them that the menu interface was fine as it was. I didn’t need them to make changes to a system I already knew. Perhaps the developers have added new features or reduced the number of clicks it takes to add a YouTube video link to my presentation; I haven’t had time to go exploring in the new version yet. Whether it turns out that I like the new version better or not, the occasion did serve to remind me that when it comes to making changes to something, whether it be a document or a digital product, it’s important to keep the user’s needs first. And how do I find out what users need? I have to ask them—again and again—until I get it right.

–Bonnie Winstel

Usability Stockholm Syndrome and User Testing in the Wild

Despite the value of usability testing in a lab, the practice has many limitations and critics, especially because using equipment in a lab is so different from the everyday experiences of users. While the immediate assumption is that using equipment in the foreign, potentially off-putting environment of the lab might bias users towards disliking a product, Jensen Harris argues that usability labs create a kind of Stockholm Syndrome, where users sympathize with their test-administering captors. That’s one reason why more companies like Firefox are conducting user testing “in the wild,” leaving the lab to seek out users in their natural habitats. Those interested in the practice can check out this free archived seminar from Dana Chisnell, a leading advocate of “in the wild” testing.

Worst websites of 2011 (so far…)

Web Pages That Suck, which has long cataloged the most egregious web design offenders, offers up contenders for the worst web design of 2011. Looking at these webpages, it’s obvious why people navigate away from poor design so quickly. Still, usability expert Jakob Nielson offers this interesting analysis of user behavior data to demonstrate how crucial the first 10-20 seconds are for keeping visitors on a web page.

User Centered Design: Satisfying the Cat

One of the issues raised in Robert Johnson’s User-Centered Technology is that user-centered design and documentation practices are ideal but are often hard to sell to corporations because of the high cost. Jacob Creech created this video, Satisfying The Cat, as an argument for why user-centeredness is a life or death issue for web design. Andrew Maier also provides a three step guide to begin implementing a user-centered culture at an organization.

Improving a Google+ Error Message

The blog Klariti Tech Writing Tips offers interesting recommendations for how to improve a Google+ error page. The tips are good considerations for any discussion of usability. And to see if the blog practices what it preaches, here’s Klariti’s own 404 error page.


Archives