Dawn Stevens, Comtech Services, Inc.

Many documentation complaints come from failing to meet the needs and expectations of the people reading the content. Authors write for their SMEs, providing all the details that the SME insists upon. They write for their editors, ensuring that the content meets a specific corporate definition of quality. They write for their managers, producing a certain volume of content to demonstrate their productivity. They may even write for themselves, adding that extra bit of information that they personally would find interesting if they were reading the documentation. The real end users, however, have no immediate influence on the content. They do not contribute to the review process and hold no power to affect the daily demands writers face to bring content to publication.

How do we give users representation within our teams during documentation development? One way is the development of personas. A persona is a detailed description of a single user type. Each persona should represent a unique set of goals, expectations, and needs. Referring to these personas will help authors keep their audience in mind as they write.

Because a persona is meant to represent a real person, it should be as vivid and detailed as possible. Anyone reading a persona should get an instant picture in their mind of the person described. You should be able to pick the user out of a crowd. Although you are not writing a biography, extra details make the persona more lifelike. For example, gender, age, and hobbies may not directly influence the way you write your documentation, but they help you relate to the user so that you can more easily anticipate their reactions to your content.

You can find a variety of persona templates on the internet. Each offers a different set of attributes to capture. Choose the template that provides the information you relate to most. Although there is no one correct template, consider including the information in the following table:

P Perceptions What do they think? What is their point of view on your area of interest? What do they like or dislike about it? What’s the difference between their view and how it should be? What problems are they likely to encounter? What causes them worry or concern?
Pain points
E Emotions How do they feel? What are the underlying emotional drivers in this area? What are their motivations in this area? What rewards do they seek? What fears do they have? What experience do they bring to the table in your industry, with your product, and with the task? What education do they have? What do they already know? In their ideal world, what kind of information would the document include? How much time are they willing to spend looking for information and learning the material?
R Roles What is their job title? What are the common tasks they need to perform? What areas of their business are they accountable for? Do they manage others?
S Strategies How and where do they get their information? How do they learn? What search strategies do they use? What sources do they consult? In what format do they prefer their information?
O Objectives What goals do they have? What information do they need to facilitate the completion of those goals? What gets in their way when trying the complete tasks? What don’t they like in other documentation they have used? What pet peeves make them abandon your documentation and look for other sources of information?
N Needs What information are they looking for? What of that information are they unable to find in another source? What conceptual and reference information support the tasks they are completing? What terminology will enhance their understanding? Do they speak English natively?
A Actions What do they do? How do they go about doing it?

To provide all this information, it’s best to gather it directly from the source. Use surveys, interviews, focus groups, and direct observation of users to gain insight about your user community. When users aren’t directly available, talk to organizations within your company that may have direct access, for example, support, marketing, and training. In fact, you may find that marketing has already created personas that you can use as a starting point. However, it is important to add specific information about the persona’s documentation needs to any existing personas harvested from another organization. You can also learn a lot about users’ needs, concerns, and tasks by monitoring user forum sites where they post questions to the community.

Remember to revisit your personas periodically, as user characteristics evolve over time. For example, new software users in the late 1980s had little exposure to the use of a mouse, but today your documentation would go in the trash if you chose to define left- and right-clicks.

Document your personas on posters or even large cutouts. Give them names and faces. Then post your personas in visible locations in your work space and on department collaborative websites. Strategically place them so they are a constant reminder of the people you are serving. Introduce your personas to new team members during new hire orientation. Bring your personas to team meetings. Your goal is to make the personas part of the team.

If you are part of an agile team, use your personas to help the team focus on user needs. In fact, your development and familiarity with the personas can make documentation the logical customer advocate on the team. Ensure all user stories reference at least one persona, and work to prioritize those stories according to that persona’s needs and expectations.

Most organizations will have more than one persona. Typically if you write trying to please them all, you will please none. Therefore, with any project or document, it’s best to specify which persona is your primary audience and which is secondary. It can also be helpful to specify an anti-persona, that is, who you are not writing for. For example, the tasks you may choose to support when documenting a cell phone would differ significantly depending on whether your primary audience is a teenager interested in texting and games or a senior citizen who simply wants to call friends and family.

Creating a persona should not be a checkbox that you tick and then ignore. Personas need to influence your day-to-day writing. As you write your content, ask yourself “What would my persona think about this content? Would she be looking for this information? Would she understand the language I’ve used? Would she be able to complete her task successfully?”

Often as a writer you will be pressured to include information by your SMEs. Personas are a good way to combat unreasonable requests. Get agreement from your SMEs about the personas you’ve developed. Then ask your SME to consider your persona’s reaction to the content they want to include. It’s important for everyone to remember: “You are not your user.”

When used correctly, personas are as important a tool as your spell checker. They can prevent you from writing content that no one needs or content that no one understands. It’s not enough to satisfy the demands of your SMES, editors, and managers. Put your users’ needs first by giving them a voice with your personas.