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.
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.
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?
I've seen at least four methods to help users keep learning an application:
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.
Get new posts delivered straight to your inbox.
I'm a technical writer based in the California San Francisco Bay area. Topics I write about on this blog include the following technical communication topics: Swagger, agile, trends, learning, plain language, quick reference guides, tech comm careers, and certificate programs. I'm interested in information design, API documentation, visual communication, information architecture and findability, and more. If you're a professional or aspiring technical writer, be sure to subscribe to email updates using the form above. You can learn more about me here. You can also contact me with questions.