Personas and other user-modeling techniques are often solely discussed as tools for product definition and design, but they are useful tools in other arenas, as well. Technical writers responsible for creating user documentation can benefit greatly from a well-defined persona set, too.
Using personas to guide your user-documentation creation-process helps you:
- Determine the primary and secondary audiences for your documents
- Prioritize technical writing tasks by giving you a tool for identifying which aspects of the product are most important to your readers
- Write documentation in a way that helps your users achieve their goals, instead of simply cataloguing all of the product's features.
Defining your audience
One of the first steps in planning a technical documentation effort is determining the audience. Sound easy? It's usually not. Often, there are multiple kinds of people who may be using your product: new users, expert users, occasional users, daily users, and IT administrators, for example. Sometimes your company's internal users, such as field application engineers who help install and customize the product, are important constituents to account for in the documentation.
The personas the design team used to design the product represent the same end users who will be reading your documentation. Understanding the personas will help you understand vital characteristics about your readership, including their technical expertise and the environment in which they will use the product.
If the persona set is large and varied, you may discover that some users have needs so distinct that they require their own section of the document, such as an advanced configuration chapter targeted at an IT administrator. If so, you'll know that you can write that section for a more technically sophisticated user.
Prioritize technical writing tasks
Being a technical writer means being near the end of the line during the product development process; there's not much between you and the shrink-wrap machine in the shipping room. Schedule slips early in the product development cycle can mean that you won't have adequate time to document the interface in as much detail as you might like. How do you figure out what to spend time on during the triage writing process?
Solid personas and design documentation can help you prioritize your writing tasks. Figure out what's most important to the persona, based on their defined goals and tasks, and document those aspects of the interface first.
Use task-based scenarios to describe the product
Persona-based design relies on user scenarios to drive the interaction design. By understanding the needs and goals of personas, the design team can focus on those scenarios that are most important to users.
Likewise, your user documentation should articulate the product in a similar way. I see many user's guides that only briefly describe what users can do with the product, and focus instead on describing each of the product's functions in excruciating detail. Describing all of the interface's menu commands and dialog boxes makes for a nice reference, but doesn't help a user determine where to start or how to accomplish her goals.
Understanding what is important to your audience can help you create task-oriented scenarios that may include using several functions in a particular sequence.
For example, if you were documenting a word processing application, you might have a section titled, "Creating a new document." The section could simply describe the File:New command and a description of the mechanism that lets you choose a document template. It answers the question, but not in the most meaningful way.
What if instead you knew that a primary persona for the word processor was a college student who would use it for writing school reports. The same section called "Creating a new document" might describe, from start to finish, all of the aspects of document creation (other than writing the content):
- Select a document template
- Choose a font family
- Modify the document header and footer
- Create a title page
- Create a table of contents
- Create a works cited section
Describing each of these sub-tasks explains to the user how to complete all of the non-writing tasks that go into creating a document. It follows a workflow that maps to the user's goal-"write my report"-rather than telling only one part of the process. A good index, and a reference appendix that describes functions one by one, will help the intermediate or advanced user who has a more specific question.
Identify special sections of your documentation
If there are multiple primary personas using your product, consider organizing your user's guide by those distinctions. Grouping functionality in this way can help avoid clutter because you won't feel the need to document every angle of a particular feature at once. Mixing advanced setup options with descriptions of daily use functions can make simple, well-designed interactions seem more complicated than they really are.
Secondary personas share most of the needs of a primary persona but have some unique needs of their own not covered by the primary persona. To accommodate secondary personas, you may want to add additional sections to your document, interleaved with the task-based scenarios for the primary persona. Highlighting these targeted sections (maybe by adding an icon or background shading) makes them stand out so that those kinds of users can find them easily in the document.
Keep personas as a tool
Don't share your persona descriptions with your users. Remember, personas are a tool for you, but nobody likes to think that they can be reduced to an archetype. A few months ago I researched digital cameras on a popular online product review site. They used a persona-like construct in a digital camera buyer's guide to help consumers narrow their focus so they could find appropriate cameras and prices for their needs. They organized the cameras into groups based on consumer archetypes: the amateur, the e-mailer, etc. To personalize the groupings, they wrote brief descriptions of each kind of shopper, but not in the most flattering way. For example, the Trendsetter type's description was:
"I like to buy the newest, shiniest toys before anyone else does. I want to impress my friends and business associates with the latest technologies and coolest features, but not if it makes the product too complicated to use. I care about how much I spend, though it's not one of my top concerns."
This is a good start for a persona description; it gives you a sense of that particular kind of consumer. But would anyone really want to classify herself as being exactly like the person in the description? Nobody wants to think they exhibit a particular behavior all of the time; we are much more nuanced than that. Personas, by design, shouldn't have those personality quirks and inconsistencies that make us individuals. They are tools and archetypes, not real people. Just like we wouldn't publish application code in a user's guide, we wouldn't publish persona descriptions, either.
A well-defined persona set can be a powerful tool. Personas are not a replacement for good product design—and they won't write any content for you, unfortunately—but they can give you confidence in your decision-making process as you plan and produce user documentation, and give you a clearly defined target to write to.