I'm starting a new series on my blog about user-centered documentation. If you're new to my blog, a series is a collection of posts (usually about 10) focused on the same topic. The series format gives me a chance to explore a topic in depth without publishing a monolithic post all at once.
User-centered documentation stems from user-centered design. With user-centered design, designers usually study their users in depth as they design products. Designers may do any of the following to get a better understanding of users:
The goals of user-centered design is to create a product that users love.
With documentation, you could do all of the same techniques as with user-centered design. However, usually technical writers don't do this kind of in-depth user analysis for at least two reasons:
I'm not saying it wouldn't be a good idea to immerse yourself in your users' environment, draw up personas based on salient characteristics, interview users about their goals and workflows, and observe them while they perform these tasks. In fact, if you do this, I'm sure your help would be really awesome.
But when these opportunities aren't available or feasible of your project, you can still create user-centered documentation by identifying common user behavior patterns and optimizing your help for those patterns.
I've had the opportunity to observe users interacting with my help content in usability labs, and it's an eye-opening experience. If you have a usability team, you should definitely make friends with the researchers and squeeze in some documentation-related usability tasks.
Here are a few posts detailing notes from those usability observations, as well as other posts from watching users:
When you observe users, you notice some common patterns. If you design your help with those user patterns in mind, your documentation becomes more user-centered.
In looking over common patterns with users, as well as looking through various books on usability, I've decided to focus on 12 user patterns. These patterns aren't in any particular order, but I believe they capture the heart of user behavior when it comes to the way people interact with documentation:
Users gravitate toward visuals.
Users learn by doing.
Users read with an end goal in mind.
Users don't read in a sequential order.
Users don't want to leave their current context to look in the help.
Users scan and jump around.
Users have different technical abilities.
Users want simple instructions.
Each user might have a different way of organizing the same content.
Users start out in the application before moving to the help.
Users often search for answers with the “wrong” terminology.
Note that I'm not necessarily addressing physical products. I'm mostly talking about software documentation, since I've always worked with software.
Based on these 12 patterns, we can design our documentation so that it optimally addresses these patterns. I'm not going to list ways to address the patterns in this overview. Instead, with each post, I'll list several strategies for taking the patterns into consideration.
After optimizing your help with these user patterns in mind, the next step is to test your content with users. You don't have to do extensive testing, but you should do some kind of tests that involve users (even colleagues) using your documentation to see if they have a “delightful and pleasing” experience. Not testing help content is somewhat akin to not testing code.
During this series, I readily welcome any feedback. Do you think I'm missing any key patterns here?
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.