Designing for People Who Struggle with Reading and Attention

Imagine you’re almost done with your taxes—but you’re ravenous and the smell of Indian food is wafting through your window, your electricity is randomly turning off for 30-second blips, and the neighbor’s infant is incessantly scream-crying. How successful will you be finishing your taxes? This session included simulations so you can get a sense of reading as a low-decoder, and of completing web-based tasks when you lack the ability to filter out distractions and/or struggle with short-term memory. We observed usability test session video clips of some of the obstacles introduced by interface design choices. You can’t design effectively for low literacy and attention disorders if you don’t understand how these issues affect people as they try to work online. We looked at good and poor design implementations of forms, touch and ajax interactions, search interfaces, and layout choices. I hope the talk helps people improve design for as much as 15% of audiences.

References in Presentation

Baumeister, R. F., & Vohs, K. D. (2004). Handbook of self-regulation: research, theory, and applications. New York: Guilford Press.

CDC Data & Statistics | Feature: Developmental Disabilities Increasing in US. (n.d.). Centers for Disease Control and Prevention. Retrieved May 6, 2012, from http://www.cdc.gov/Features/dsDev_Disabilities/

H.L. Chace, 1956. Anguish Languish. by Prentice-Hall, Inc. Englewood Cliffs, N. J.

Resources in Presentation

Captcha Alternatives

http://www.evengrounds.com/developers/alternatives-to-captcha
http://webaim.org/blog/spam_free_accessible_forms/
http://www.90percentofeverything.com/2011/03/25/fk-captcha/

Writing and Plain Language

http://www.plainlanguage.gov/
http://www.centerforplainlanguage.org/
http://www.centerforplainlanguage.org/aboutpl/guidelines.html
http://www.plainlanguage.gov/howto/wordsuggestions/simplewords.cfm
http://owl.english.purdue.edu/owl/resource/539/1/

Tools mentioned in the presentation

Clickstream Data

• Google Analytics (robust clickstream data)
• Adobe Omniture (robust clickstream data)
• IBM CoreMetrics (robust clickstream data)
• CrazyEgg (heat maps)
• ABTests.com (A/B testing)
• Google Website Optimizer (A/B and multivariate testing)
• Facebook Insights
• Social Bakers Facebook Statistics

Competitive Data

• Google Insights for Search (search term trends)
• Compete.com (competitor search term data)
• Google Keywords Finder Tool

Surveys

• 4Q (customer satisfaction survey)

Resources mentioned in the presentation

• Google Analtyics Event Tracking Guide (tracking non-html events such as PDF downloads and Flash movie plays)
• Search Patterns: Design for Discovery (book by Peter Morville and Jeffrey Callender)

People mentioned in the presentation

Dana Chisnell
@danachis
Co-author: Handbook of Usability Testing
www.usabilityworks.net

Richard Dalton
@mauvyrusset
Presentation: A Practical Guide to Measuring the User Experience

Avinash Kaushik
@avinash
Blog Post: Rethink Web Analytics: Introducing Web Analytics 2.0

Lynne Polischuik
@lynneux
AnalyticsForUX.com

Erin Richey
@erinjo
Presentation: Qualitative / Quantitative – Learn More About Your Users With Web Analytics

Two Banks

I needed to pay some bills. I went to check one account but couldn’t remember the password my husband said he’d changed it to. I clicked the forgot password link and was asked for my email address. I received an email with a link, which took me to a page where I could reset my password. I changed it and got into the account, but unfortunately, did not have enough in that bank account to pay the last bill, due the next day.

So I went to my other bank’s dreaded website, and tried logging in. Firefox prefilled the password for me. “Invalid password.” I rarely know this password as you’re require to change it every two months, and you can not repeat any of your last six passwords.  My fear began to mount. I knew I only had two more tries and then the website would lock me out. There is no forgot password link. If I got locked out, I not only would have to wait for regular business hours, I’d have to physically go to the bank two towns away because they can’t achieve the magic of resetting passwords at the branch in my town. But I had no choice. I had to try to pay the bill. Sure enough. I ended up locked out, and taking a long lunch the next day.

Stories prime the room for conversation

I’ve been reading Whitney Quesenbery and Kevin Brook’s book, Storytelling for User Experience. While the book has useful tips about using data-rich stories throughout design processes, it has made me aware of my need for a bank of stories for persuading people about common user experience pitfalls. When we have a good bank of stories on hand, we can use them to set the scene for exploring solutions. What stories do you use to help people value user control?

As a lone UX’er (for the most part) in my job, I relish the chance to learn from fellow user experience folks face-to-face. I’ll kick that off with Dan Saffer’s Brainstorming and Design Principles. There are quite a few brainstorming techniques in Saffer’s book Designing for Interaction that I have not tried, and would love to see a good brainstorm leader put into action. For instance, there’s the ‘Force Fit,’ where you “distill a problem to two words in opposition, then put those words together into a phrase.” The idea is to then think about what exists in the world that embodies the phrase and apply it to the project for inspiration. I also could use some guidance when it comes to organizing concept drawings: when to try for a 2×2, grid alternatives, etc.

I hope the morning session doesn’t wear me out before The Right Way to Wireframe, with Will Evans, Fred Beecher, Todd Zaki Warfel, and Russ Unger. I’m primarily a paper-to-html girl, with more and more 8Shapes Unify these days, though I’ve spent too little time with Axure and OmniGraffle. This session will get participants working in teams with different tools to address a local business problem. We’ll see how the tools affect ideation, and have a few hours of designing together. Sweet. I expect to laugh most of the way through and hope the party continues afterward.

There will be a UX Book Club session discussing Saffer’s book as well as Jon Kolko’s Thoughts on Interaction Design. (I have the book but need to hurry up and read it!) I coordinate UX Book Club Brattleboro, here in southern Vermont, but we’ve had low turnout. I hope to get some ideas about drumming up interest. Kolko’s giving a keynote on interaction design’s role in shaping culture, and his take on “three fundamental problems: a lack of quality, a lack of competent leadership, and a misappropriation of our skills.”

Some of the sessions I’m most looking forward to include: Liz Danzico (Frames: Notes on Improvisation and Design), Chris Fahey (The Human Interface (or: Why Products are People, Too)), and Livia Labate (talking about measuring UX success, something I’m particularly focused on these days). I’m hoping there’s a Deus Ex Machina moment and Fahey & Labate’s sessions get moved to separate time slots. Cindy Chastain gets raves for her storytelling and experience themes workshops, and I missed her speak at the 2009 IASummit. Though if you’re attending, I highly recommend Peter Morville’s Future of Search. I was fortunate to attend his terrific UIE Virtual Seminar last week. Morville got us thinking about how we facilitate fluid movement between searching and browsing, and how we implement search to help people find what they’re looking for & discover what they didn’t know existed. He encouraged that: “Good search requires a telescope to look ahead, a microscope for obsessive attention to detail, and a kaleidoscope to blend patterns.”

There’s a session, Use of Virtual Worlds Among People with Disabilities (Kel Smith) that intrigues me, and I’ll be participating in Dan Willis and Donna Spencer’s Visual Thinker’s Pictionary. Will you be there? What are you looking forward to?

I’m staying through Monday, with full expectations of a superbowl party. Don’t let me down, people.

I heartily recommend Luke Wroblewski’s Web Form Design (May, 2008) for people who create web forms and for those who hire others to create them. The book is structured in three parts: form structure, form elements, and form interaction, and includes a plethora of real-world examples. Whether you’re a novice or expert, walking through Wroblewski’s overview of forms-related issues will provoke your thinking about design choices and their impact. Luke is Chief Design Architect at Yahoo! and blogs at Functioning Form.

Below are some of my thoughts and recommendations in response to the book.

Deepen your understanding of other people’s experiences

Who are we to not bother to ensure the resources we create are universally usable? As you are thinking about making better web forms, deepen your understanding of how design choices affect people with disabilities.

Peter Wallack wrote an accessibility piece for Web Form Design, offering a list of the “most important” accessibility requirements to consider. He reminds us that it is up to website designers to ensure their forms are accessible to millions of people with physical and cognitive disabilities.

Wallack urges us above all, “Test your page with your intended users, including those who have disabilities.” There is broad diversity among people with disabilities and their approaches to using technology. Shawn Lawton Henry offers suggestions for recruiting participants with disabilities in her book Just Ask: Integrating Accessibility Throughout Design.

Check out this YouTube accessibility playlist of people talking about their disabilities, demonstrating using a variety of assistive technologies, and speaking of their experience using the internet:

“…I feel often ashamed because I can’t use it as well and I’m not that old; I’m quite young… And it becomes a battle and it should be a level playing field. The web should have created a level playing field for visually impaired people and disabled people as a whole, and what I feel sometimes the web does is it actually blocks people out and it isolates you more.”
Kirin Saeed, a screen reader user discussing her experience using the web (link: youtube video).

As web designers and developers, we all make things for people to use. If you are not working on making your resources accessible, you are making a choice to block some people out. This can cost you and your clients or your organization money. And it causes great frustration for real people. When we talk about accessible, or universally usable forms, we’re talking about Kirin, (above). We’re talking about Jessica Cox, the pilot who has no arms who flies a single jet engine using foot controls. She recently flew a plane from Arizona to Wisconsin, but she might not be able to fill out your web form because you didn’t bother to make it accessible to alternative input devices. We’re talking about friends with muscular sclerosis who must use extreme effort to control a mouse, with minimal success. We’re talking about brilliant co-workers who have non-verbal learning disabilities and will spend inordinate amounts of time trying to divine what unfamiliar abbreviations, idiomatic expressions, and unclear icons are meant to convey.

In addition to listening to people talk about their experiences, learn to browse your pages with alternative methods. Try listening to your web pages with the web-based screen reader WebAnywhere. (Better still, install the free NVDA screen reader (Windows only) and learn how to test with NVDA.) Become proficient in keyboard navigating the web. I would bet that if you spend any time moving around a web page with only your tab key, you’ll quickly get a sense of how important it is to maintain (or enhance) the unformatted dotted line box decoration of links when they have focus. As you deepen your understanding, you’re likely to create fewer problems that need fixing.

Why are people filling out your form?

Recently, before giving a presentation I surveyed attendees about their typical workflow. Generally, people described getting fields identified by the client, doing some layout, and testing to ensure it works. Nobody said anything about identifying who will be filling out the form. In Web Form Design, Caroline Jarrett (author of Forms that Work) encourages us to think about people and relationships, and to balance user and business needs.

So what are some things that are helpful to know about how the form will be used? What do people need with them? Where might they be when filling out the form? If they’re on a mobile device, do their needs change? What will they need to do with the transaction in a month? How often will individuals use the form? How will the data be retrieved? What will it be used for? It’s often a big mind-shift for clients to think in terms of the people coming to their forms. It is far more common to be thinking of the data entry you will do in order to complete your own tasks, than to consider the experience of the people filling in the forms. Addressing recovery issues, such as what happens if a person is interrupted or needs information they don’t have with them at the moment will make your form more usable. In the last few weeks, I have twice purchased things over the internet on my phone. Neither website sent me an email copy of my receipt. If the designers had considered that I might be purchasing something for my business or that I would be on a mobile device, I would be able to supply a receipt to my accounts payable office. Another important consideration is the frequency with which people will use a form: Wroblewski points out the tradeoff between making forms highly efficient versus encouraging well thought-through answers.

Measuring Usability

Web Form Design includes an overview of measuring how effective, efficient, and satisfying forms are to use, by assessing things like successful completion, abandoned forms, completion time, number of help requests, number of errors, satisfaction after submitting the form, and common issues in call center logs. Throughout the book, Wroblewski points to results of various usability studies, in support of various recommendations for layout of forms, alignment of labels, use of progress meters, etc.

Social Rules for Forms

Wroblewski underscores the notion that forms are conversations, and need to be approachable and respectful. Our forms are stand-ins for our voice. They are what makes the web two-way. Wroblewski notes that forms stand between people and productivity and they help us close deals. Michael Angeles said, “After all, if software is to be social, then it may as well learn social skills.”

What face-to-face social interaction rules should our forms follow? Only ask what you need to know. (No impertinent questions! If you and I had just met, I wouldn’t ask you for your street address unless you asked me to send you something.) Be friendly.

Avoid speaking for your site visitors. If forms are a conversations, the questions are the website’s side of the conversation, and the form inputs are the other side. Phrase your questions accordingly. Many forms, instead of asking questions, speak in the voice of the user. For example, field labels such as: “My Address.” “Sign me up for a trial now.” “Please contact me with more information.” Speaking in the voice of the user removes the opportunity to have a conversation with the person. You also run the risk of the person reacting negatively to something being said for them. (I’ll report back if I get a chance to test this with people.)

Build User Confidence

Here’s a picture from a gas pump. “Insert Card Fully. Withdraw card quickly.” What response do you have when you encounter this? What’s going to happen if I fail to remove the card quickly enough? Perhaps not everyone gets panicky when they encounter these signs. Nevertheless, we don’t want to create that unsure feeling of “What if I mess up?” for people filling out our web forms. Our designs should reassure the user that they have control over the form in as many ways as possible.

Wroblewski suggests form should have reduced noise and contrast. He suggests calling to mind soothing rooms and a friendly smile. I’ll go a step further and suggest you think of Mister Rogers. Remember when he promised we would never, ever go down the bathtub drain? Our forms could strive to be that reassuring. Mister Rogers, or someone you know, can act as your Reassurance Genie. When you create a form, do a ‘reassurance genie’ test as part of quality assurance. Call your reassurance genie to mind. What would they think of your error messages? Of your confirmation screen?

Provide a clear path to completion

The goal of our forms design, well-stated by Wroblewski, is to provide a clear path to completion. The decision to do a single page versus multiple pages is not clear-cut. The drawback of multiple pages on an unfamiliar site is a lack of trust that people will be able to go back and forth between pages if needed without losing data. We must do everything we can to facilitate recovery and reassure users that they will be able to change their entries. When a form is rather long, and there are logical breaks, one might decide to do a paginated form, either with links such as ‘Continue’ and ‘Go Back’ or as a series of tabs. Progress meters indicate stages of multi-page forms. Wroblewski describes the essential aspects of successful progress meters: They should explain the scope of the form (that is, how many steps or pages), they should show your progress and location (that is, where are you along the path to completion), and they should accurately reflect the actual steps. It is critical that people can go back and forth through pages without losing their data, and with the ability to make changes.

Form Labels and Fitts

Web Form Design includes a chapter on labels (the text associated with a form field). Wroblewski compares various layouts of labels and their fields, answering questions such as which layout results in the speediest completion, which requires the least effort, and which scales best to accommodate growing text. Luke covers some of this in his slides Best Practices for Form Design on slideshare.net.

WFD does not touch on Fitts’s Law and coding form labels and input fields such that they are explicitly associated with each other in the code behind the page.

Fitts’s Law states, “The time to acquire a target is a function of the distance to and size of the target.” The further away a target is, the larger it needs to be to maintain access speed. Bigger things are easier to hit. This seems obvious as I say it, but do you take this into account when you create a form? Think about toolbar icons as an example. Some toolbars offer the option of displaying a label below each tool. Labeled tools can be accessed faster because the label becomes part of the target. The target is therefore bigger. Bigger targets, all else being equal, can always be accessed faster. When labels are not used, the tool icons crowd together, and are easier to miss. When targets are large, you don’t have to slow down so as not to overshoot the target.

Label tags are the HTML tags used in the code behind the form. Label tags affect how much is clickable on a form. When the label tag is used, the button and the text all become clickable. (In the example on the left, the green areas are clickable. Making the target area much larger will improve completion time (efficiency) and make your forms easier to use. Labels provide this benefit for checkboxes, text boxes, and other form fields.

Form labels are crucial for accessibility. Using a label explicitly (that is, using the ‘for’ attribute to refer to a unique ‘id’) tells a screen reader which label is associated with which input field. While the input field has focus (that is, while it is selected), the browser will recognize the connection between the label and the input. In the case shown in the image, a screen reader will speak, “Mushrooms Radio Button not checked. One of three.” Any time this radio button has focus, it will indicate it is the mushrooms option and how many other options there are. If the code does not explicitly make the association of the label and the input, the screen reader will read “Radio button.” The screen reader will then say the text “Mushrooms” and the user will have to tab backwards in the form to select the radio button, never being sure they’ve actually selected the radio button they intended to select. Roger Hudson offers details about how screen readers read labels and form fields.

Avoid placing labels inside inputs

Wroblewski talks about some of the pitfalls of placing labels inside inputs, a technique used to reduce impact on screen real estate. Sometimes the text inside the input is a secondary prompt of what to enter in addition to an actual label (as in the example on the left). Other times it is the only information indicating what the field is for. Often labels inside inputs are light gray to distinguish them from real answers. Frequently the light gray provides little contrast to make it readable by anyone with reading difficulties or trouble distinguishing color. The common behavior of the text inside the input is that it goes away when the input receives focus and the person enters any information. What if you click on the label, hit the spacebar, and the phone rings. When you come back, will you know what the field was for? Will you need to refresh and lose the other data you had already entered? A person who is blind may tab through all of the fields to see if they’re willing to fill out the form. For any fields where they start typing, when they go back through the form to fully fill it out, the labels will be gone. What if the person entered something unreadable, for example their fingers were shifted on their keyboard and they hadn’t noticed? How will you know what the question was? What if you’re on a touch device and you fat-finger the field before you read it? Labels are generally put inside inputs in order to create a cleaner-looking field, or reduce the vertical length of the form. However, the usability trade off is not worth the gain. Regarding color contrast, I recommend Gez Lemon’s Firefox Extension, the Colour Contrast Analyser. It provides a report of all of the color contrast combinations in a page, indicating which pass contrast validation tests and which do not.

Captcha Alternatives

Captcha stands for “Completely Automated Public Turing test to tell Computers and Humans Apart.” This screen shot is from Google’s account creation page. It shows a very difficult-to-read captcha word that must be typed in the field below. Sometimes, these at least offer the ability to request a new word, but not here. One could refresh the page repeatedly until getting a legible ‘word,’ but you would have to re-enter the information you had already filled in. If you have reading or vision difficulties, you can click on the wheelchair. What do you think happens if you click on the wheelchair? It plays audio of the letters. I don’t know about you, but a wheelchair doesn’t make me think of audio (or reading difficulty for that matter.) The audio is not helpful if I’m in a situation where I need my device to be silent. As a spam-reducing alternative to captcha, consider using CSS to hide a form field with an empty value. You can then use server-side form validation to check to see if a spam bot has unwittingly filled in this field. You can see an example of this looking at the code on an interest form. WebAIM offers instructions on spam-free accessible forms.

Dismissable error messages trip people up

Beware of dismissable error messages, like the one depicted in this screen shot. This is an example where you submit a form and a box appears with information about errors that need to be fixed. It may be worded in a very friendly matter. While most modern screen readers can read such an alert message, many people struggle with short-term memory issues. In order to fix the form errors, you must dismiss the alert message, losing your instructions about what needs fixing. This type of alert is the default for things like the Adobe Cold Fusion <cfform> tag, which is designed to reduce the effort of people creating web forms.  People will be far more able to recover from their errors when the system feedback (such as error messages) is persistently available. Web Form Design includes many examples of error and success messages, as well as validation treatments before form submission.

Don’t forget the confirmation screen

Confirmation screens are an important part of the conversation between the form and the user. Too often forms say thank you and don’t bother with any detail. Include information about what will happen next with regard to the transaction. (Only offer a promise you can keep!) Show the person the information they submitted. It is very reassuring to the person submitting the information and it provides a means for them to check their submission. Provide your contact information: how can they get in touch if they made an error. If they can not contact you directly, give information about how they can adjust their submission. You can also use this opportunity to keep them on your site by providing links that may be useful based on the form they just submitted, or as Wroblewski puts it: encourage more progress.

11/2009 narrated presentation: Universally Usable Web Forms