Search results

Changing the Rules of the Game for the Benefit of the User

by Tom Johnson on May 8, 2008
categories: technical-writing

Presenter: Joe Sokohl (http://sokohl.com)
Conference: Doc Train West 2008

In this presentation, Joe Sokohl talks about gathering user research prior to designing and implementing your help deliverables.

Breaking the Rules

First you have to get to know the user by talking directly to real users doing real work in actual contexts. Interview real people doing real activities. "Don't speculate, don't argue. Observe" (Don Norman). Everything starts with user research.

Joe interviewed actual users in their cubicles and offices, asking them how often they used the product and how often they did various tasks.

He also said, "By the way, could you show me the user manual for this software?" Hardly anyone could produce the manual. One lady finally dug it out at the bottom of a cluttered drawer.

Joe says companies often tell technical writers, "You can't talk to users." This is such a ridiculous rule. It's one you have to either break or find a workaround for. Eventually you need to make contact with users in their offices, labs, and cubicles. Find out the information sources they read, the frequency with which they use them, the time they've spent in their position and with the company. Ask them questions such as,

  • Where do you go for information?
  • What books do you go to?
  • What sources of information do you read?

In short, conduct behavioral interviews. When you interview actual people, you find out an enormous amount of information.

Major Findings

After interviewing users, Joe found the following:

  • Users hated standup training
  • Users didn't use manuals
  • Users found out things mostly on their own at their own pace
  • Users wanted some control over what they learn

Sometimes companies have expectations for you to deliver a certain kind of content, but the deliverables they ask for don't match what the users want. Their deliverables don't match the user's behavior.

For example, in Joe's situation the company execs wanted step-by-step Powerpoint slides, but through research Joe found that users hated standup training. They also disliked manuals -- another deliverable the company wanted him to create.

From his interviews, Joe created several personas (driven from the data, not from imagination). He included realistic details that represented the most common attributes of users. He then created scenarios for the personas that tell stories.

Design and Deliver

After you find out what users truly want, design and deliver the help deliverables that fit their needs. (Of course you may have to also deliver what the company wants, but you can show the company execs results from your research and argue for a different course of action.) Essentially you want to create training that users find engaging in the context that is appropriate for them.

When you propose your solution, also keep in mind platform issues, such as restrictions within the existing system architecture, the ability for the client to continue adding on to the material, and so on.

Conclusion

A lot of times company execs make decisions based on their own experiences, based on personal contexts and learning styles that are different from the users' contexts and experiences. But these assumptions can lead you to create the wrong deliverables. You have to find out who the users are, what they need, and then design help materials that fit their needs. You often have to break the company's rules to make contact with users to get this information.

Joe found that users really didn't want user manuals. They wanted quick information for exact tasks, and user manuals didn't meet that need. To meet their needs, Joe created a quick table of contents that pointed to Captivate demos.

Additional Reading

Joe recommended some additional reading: Kunavsky, User Research, and Alan Cooper, About Face.

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.