Using personas to create user documentation
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
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
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