Search results

"I never really understood that feature, so I left it alone..."

by Tom Johnson on Feb 12, 2010
categories: technical-writing

The other day I rose early to conduct some user acceptance testing with a new version of our software. As I was going through the new version of the application with a user, he got excited about a new feature we were implementing, which allowed users to collaborate on items. Noting his excitement, and realizing that the new version of the software wouldn't be released for several more months, I explained that the current version had a similar feature as well that he could use.

Oh, that field? he said. I never really understood that feature, so I left it alone.

The user wasn't a novice. He used this application several hours a day, if not more. How could he be so comfortable leaving alone a feature that could be integral to his workflow, which could save him hours of time and make his life easier? I could hardly believe it.

Knowledge Intake Thresholds

As I related the feedback to my colleagues, they noted how we often do the same thing with applications we use. For example, I use iTunes to download podcasts, create playlists, and sync the audio to my iPod. I know iTunes can do a whole lot more, such as create smart playlists based on the music I most often play, but I'm not interested in that. I don't quite know how to set it up, and frankly I'm happy with my current level of understanding.

Photoshop is another example. I can get by in Photoshop all right. Only when I absolutely have to learn something, such as layer masks, do I start pushing my knowledge deeper by going into the help.

I often give one-on-one WordPress training. This past Saturday I scheduled a two-hour call with someone implementing a wootheme. At about an hour and a half into the call, I could tell the person's brain was saturated. I had hit the threshold on her knowledge intake for the day.

My own knowledge intake threshold maxes out at about an hour. This is why classes at schools aren't longer than 50 minutes. After an hour, the amount of new knowledge you can continue to absorb goes downhill.

Long-Term Learning

As technical writers, it's hard to feel empathy for users when they refuse to learn. It's all in the manual, if they would just read it, we often say. But we have to remember that we spend months ramping up on a software application -- users don't. Our first experience of the application is usually in a development environment where features are only half-coded. As time passes and new features are developed, and we attend project meeting after meeting, we slowly add the new knowledge to what we've already learned. After six months of gradual ramping up, we're experts on the application. We then try to teach users to be experts in a day, or more realistically, in about 20 minutes.

Do you see the problem? We get six months to learn little by little, being paid handsomely to do so. The user gets 20 minutes and must often take time out of his or her schedule to do it. It's no wonder the user doesn't naturally move into the expert knowledge range.

A more practical way to learn new software is to approach it bit by bit. An hour a day over the course of a month can be more helpful than a crash course. But how do you keep the user learning every day or week?

Strategies to Keep the User Learning

I've seen at least four methods to help users keep learning an application:

  • Daily tips. Some applications show a daily tip in an attempt to increase your knowledge little by little. However, these tips are often as successful as ad pop-ups on websites.
  • Regular newsletters. Some companies provide a regular newsletter about their products. For example, TechSmith provides a periodic newsletter that usually has a couple of tips for using Camtasia Studio and Snagit. I scan this newsletter and will watch a video tutorial on a feature I'm unfamiliar with.
  • Product blogs. Some products are robust enough that the company has an entire blog focused on the application. Microsoft Office is one example.
  • Interface tips. When there's a new feature added to the application, the interface often highlights what's new through a little bubble caption. This is common in Gmail.

Encouraging Desire

Besides these methods, I'm not sure what you can do to help users continue to increase their knowledge of an application. The problem is that even if you provide the means for advanced learning, whether through tips, newsletters, blogs, or interface notes; users already familiar in performing a core set of tasks are inclined to remain in their comfort zone.

In their minds, they already know the application. Or they know it well enough to get by. As with most things in life, the problem in helping users learn isn't so much strategy as awareness and desire. They often don't know what they're missing. So they don't care about missing it.

About Tom Johnson

Tom Johnson

I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.

If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.