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.
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,
In short, conduct behavioral interviews. When you interview actual people, you find out an enormous amount of information.
After interviewing users, Joe found the following:
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.
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.
Joe recommended some additional reading: Kunavsky, User Research, and Alan Cooper, About Face.
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 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.