One day I spent much of my time with a person who was new to a desktop application I work on. I provided documentation for the application, but this particular person—I’ll call her Ann—tends to doubt her ability to learn. So I was happy to work with Ann one-on-one to help her learn the steps of a procedure she would use at least weekly (and that she knows well at this point, I’m happy to report).

As we talked, Ann decided to open a new Word document to work in. I watched as she went into her file system and located a document with the file name “blank page.docx.” She double-clicked it to begin a new document.

I was somewhat surprised and even a little amused.

But watching Ann do this reinforced for me that even those tasks that some of us see as easy and routine aren’t that way in other people’s heads. To her, opening a document called “blank page” and then saving it as something else made sense.

I thought about telling her about Ctrl+N, which is my method of choice. There’s also using a desktop or quick launch shortcut or going to the Office button and then clicking New. But I decided to leave it alone. I had more important things to teach her that day, and she already had a method that worked for her.

What does this mean for user experience design and technical communication? A few things, I think.

  • Left to themselves, users of our products may or may not figure out some way to accomplish a task. If they figure it out, their method may or may not be optimal. It’s our job to provide the optimal path to success.
  • Addressing the most important concepts first is essential. While I could have diverted my conversation with Ann to talk about opening a new Word document, she probably wouldn’t have remembered without some repetition later. Word was off topic. I needed to keep her focused on the specific task she was trying to accomplish. A reminder to not divert users’ attention from the task at hand when it’s not needed.
  • Usability has to do with giving people familiar patterns and few steps, not designing things and expecting training—or worse, the so-called intuitive design—to get the users through. They won’t do what we expect, and it’s better to design things to fit people’s mental schemes than to get them to learn something new.
  • Because of the previous point, we’ve got to take time to watch users try out our products. An example: In another of our applications, a check-printing wizard includes a step where the user must indicate if each check “Needs Reprinting?” and they select Yes or No. But we’ve found that people are doing it backwards; they’re not looking closely, and they think they’re being asked if each check printed correctly. So we’re changing the text and swapping the code so that it conforms to what people expect to see. Having some users try it early in the process would have saved a lot of support calls when people found their payments kept going back into the queue to be printed (they thought they were saying “Yes, they printed correctly”!).

Remember that the unexpected will grab your lapels and give you a shake in circumstances like this. Over six billion people inhabit this planet, and they don’t all think alike. Plan ahead for the fact that at least some of your customers and users won’t do what you think they will with your product. And if you don’t know your audience, it’s even possible that most of them won’t do what you expect.

Related posts (auto-generated):

  1. Fight User Frustration: Give Users What They Expect
  2. Consider Users' Environment as Part of User Experience
  3. Forget the Scry: Find out Why Users Access Help
  4. I'll Have the Printed Color Surprise, Please
  5. Spending Time with Users to Learn How They Want Assistance