Adobe Robohelp

Get new posts delivered straight to your inbox.

Subscriber count: 3,505

Stitcher radio

follow us in feedly

Want more tech comm blogs to follow? See my Tech Comm Collection of Blogs on Feedly.

Adobe Robohelp

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

May 8, 2008 • general

Presenter: Joe Sokohl (
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.


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.

follow us in feedly

Get new posts delivered straight to your inbox.

Subscriber count: 3,505

About Tom Johnson

Tom Johnson

I'm a technical writer based in the California San Francisco Bay area. Topics I write about on this blog include technical writing, authoring and publishing tools, API documentation, tech comm trends, visual communication, technical writing career advice, information architecture and findability, developer documentation, 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.