Using Personas During Design and Documentation

By Niranjan Jahagirdar and Arun Joseph Martin

Published: October 18, 2010

“How did the writer of your application’s documentation know how to meet your needs? The most likely answer would point to the effective application and use of personas.”

Picture this scenario: You are using an application to work on a time-critical project, and suddenly, you are stuck for want of information about a particular screen. Time is running out. You reach for the application’s documentation and spend a few minutes trying to figure out what to do next. Thankfully, you are quickly able to locate the relevant information and continue with your work. You are pleased with the documentation and praise the unknown writer.

In this case, the application’s documentation served your needs well. How did the writer of your application’s documentation know how to meet your needs? The most likely answer would point to the effective application and use of personas.

What Are Personas?

Personas are fictitious users you create based on your user research. Personas summarize your user research findings and provide a practical approach to understanding the requirements of your target audience and keeping user perspectives in mind when designing products and creating documentation for them.

“Personas … provide a practical approach to understanding the requirements of your target audience and keeping user perspectives in mind when designing products and creating documentation for them.”

However, bear in mind that, although demographics and task analysis play an important part in persona creation, personas are more than just a collection of user profiles and groups. You should make them as real as you can. They should embody all the human attributes you’d expect to find in your users. For example, they could be moody, very task oriented, work in a specific type of environment, or even hate the idea of referring to documentation unless they are absolutely compelled to do so. To understand the implications their projected reality might have, consider the following persona:

Manas is a technical author with 12 years of experience. In addition to being a busy writer, he spends many hours daily replying to email messages and mentoring his colleagues—answering questions about using the tools his team employs in producing documentation, different types of documentation, and life at work. Manas connects to the Internet through a wireless connection that never fails and spends hours researching answers to questions about writing. Oddly enough, he actually reads computer manuals and online Help for fun, and he has quite a few books on writing and communication competing for space with his Terry Pratchett novels on the bookshelf in his office.

Note this persona’s level of detail versus that you would find in a user profile. The amount of experience Manas has in his field is specific, the persona clearly describes his work environment, and his quirks are apparent. In short, you have a fake, but uncannily real user in whose shoes you can walk when designing your product or writing its documentation.

We both work on documentation, so for now, we’ll focus on using personas in creating the documentation for a product.

What would the implications be if you were writing documentation with Manas in mind? To meet his needs, you might deliver documentation in the form of email messages that ask leading questions and direct him to answers, catering to his mentoring nature by encouraging him to share them. You could reach out to Manas by creating sponsored ads on Google, so when he uses his Web browser to do research on a topic relating to the use of your product, he would find links to relevant documentation on your Web site. Such dynamically generated links provide an effective and efficient path to your documentation. Plus, the presence of your documentation on your Web site implies that Manas has instant access to your most recent, minimalist documentation whenever he’s exploring and wants to find alternative channels of learning.

Where Do Personas Fit in the Documentation Development Lifecycle?

A typical documentation development lifecycle (DDLC) has six stages. 

  1. Requirements analysis
  2. Documentation planning
  3. Writing
  4. Reviewing
  5. Production
  6. Archiving
“The planning and writing stages usually occur when writers know the least about users. This is why creating personas during requirements analysis and documentation planning is optimal.”

As the documentation development lifecycle progresses, writers develop greater attachment to their perspectives on what the documentation should be. Their ideas begin to crystallize sometime between their developing a documentation plan and starting writing. They show more openness to making heavy changes to a documentation deliverable during the writing stage than afterward—say, at the review stage. Ironically, the planning and writing stages usually occur when writers know the least about users. This is why creating personas during requirements analysis and documentation planning is optimal.

Figure 1—Persona development in the documentation development lifecycle

Persona development in the documentation development lifecycle

The benefits of developing personas at the beginning of the documentation development lifecycle are numerous. This approach

  • ensures that writers focus on users and are empathetic to users’ goals
  • encourages consensus among various stakeholders
  • equips all stakeholders to make better decisions
  • leads to an efficient documentation process

Developing Personas

This persona-creation process is applicable whether you are creating personas as a basis for product design or documentation.

Laying the Groundwork

“Two main types of needs define any product or solution that people use, be it software or documentation: business needs and user needs. You need to collect and analyze a lot of data before you can create personas.”

Two main types of needs define any product or solution that people use, be it software or documentation: business needs and user needs. You need to collect and analyze a lot of data before you can create personas. Thus, your personas should be distillations of these needs.

To assess user needs, you can start by interacting with the people within your organization who work directly with users—for example, your sales, support, and marketing teams, technical sales consultants, or any other groups who have information on demographic profiles.

You can also conduct user research to help you understand user goals, tasks, and attitudes. For an existing product, this might involve observing or talking with actual users about both their problems and positive experiences using your product. For a new or existing product, you could do user research with people who are roughly like your prospective users in order to help you understand their needs. In general, there are two distinct approaches to user research:

  • quantitative—Quantitative approaches to user research include measurement of user preferences through user surveys or of users’ behavior through site traffic or log analysis. Such studies allow you to obtain data from a large user population, have a low per-user cost, and give you a fair idea about what is happening, but they do not tell you why.
  • qualitative—Qualitative approaches to user research include measurement of user goals, attitudes, and behavior through user interviews, focus groups, diary studies, ethnographic studies, and to an extent, opinion surveys. Such research endeavors typically involve small sample sizes, are usually expensive, often allow you to discover new things, and have the potential to provide very rich data about why users behave in a certain manner. These studies don’t prove anything, but can work very well if you want to validate the efficacy of your design and architectural changes.

Considering the differences between the goals and results of these two approaches to user research and the fact that most writers work on a tight time-and-cost budget, an ideal, practical approach to user research includes the following steps:

  1. Conduct qualitative research. User interviews are the most common form of qualitative research. Some companies conduct field studies, observing users’ behavior and asking them about their goals and attitudes. In addition, you can do usability testing to observe user behaviors—though this is less common.
  2. Segment users into groups based on the research. When creating personas, the goal of this step is to find patterns that enable you to group similar people together into types of users. This segmentation is typically based on user goals, attitudes, and behaviors.
  3. Create a user profile for each segment. Each type of user evolves into a persona as you add more detail about their goals, behaviors, and attitudes.

Assuming your project does not have a very constrained budget, here are two cases in which a project could benefit from applying this approach:

  • if your stakeholders don’t need to see quantitative data to believe in and use your personas
  • if you want to try creating personas for a smaller project to see how well they work before applying them to the larger business

The Process of Creating Personas

“Our persona-creation process kicks off once our user research is complete.”

Our persona-creation process kicks off once our user research is complete. It involves the application of our research findings through a well-defined process.

  1. List the user attributes. Assemble all of your product’s stakeholders and ask them to make a list of user attributes—for example, Male, Computer literate, or Plays football.

To help you easily categorize the information you’ve obtained about your users, you can use the following categories of attributes:

  • Demographic
  • Technological
  • Internet Usage
  • Environment
  • Lifestyle
  • Roles
  • Goals
  • Needs
  • Desires
  • Knowledge
  • Usage Trends
  • Tasks
  1. Cluster the attributes. Once you’ve gathered your list of user attributes, cluster the attributes. To accomplish this, ask one of the stakeholders to divide his or her user attributes into several clusters. Then ask another stakeholder to place any related attributes in those clusters or, if his or her user attributes don’t fit into any of the existing clusters, to create new clusters. Repeat this exercise with every stakeholder until you have clusters that everyone agrees on.
  2. Create a persona for each of the clusters. Add personal details to create a realistic picture of a user, focusing on specific user needs. Note down tasks that persona is most likely to perform. Think about how the attributes in the clusters influence user behavior.
  3. Prioritize personas. Prioritize the personas on the basis of business needs. The idea is to ensure that the principal persona you use during design or documentation is a clear and correct representation of your primary user population, not an edge case.
  4. Tell stories, or create scenarios. The stories or scenarios you create for each persona describe how that person would behave or think about a particular task or situation.
  5. Create persona documentation. When writing personas, include the following information:
  • name of the persona
  • demographic description
  • goals
  • needs
  • abilities

Benefits of Creating Personas

This approach to creating personas offers many benefits, including the following:

  • It requires a relatively low amount of effort, time, and cost. For example, you could interview internal users or conduct interviews with less than 10 users and create personas within two weeks.
  • Using personas and scenarios increases understanding and stakeholder buy-in.
  • Persona-creation requires fewer specialized skills, in comparison to other approaches.

Since, for the most part, our approach to creating personas is based on the subjective understanding we and other stakeholders’ have of users, it’s best to validate the personas through quantitative studies. Covering that subject will require another article.

Recommended Reading

Calde, Steve. “Using Personas to Create User Documentation.” Cooper Journal, December 2, 2004. Retrieved August 16, 2010.

Millman, Barry. “New Technical Writer: Use the Persona to Create the Most Useful Section of Your User Document.” Article Alley, March 12, 2007. Retrieved August 16, 2010.

References

Mulder, Steve, with Ziv Yaar. The User Is Always Right: A Practical Guide to Creating and Using Personas for the Web. Berkeley, CA: New Riders, 2007.

Kuniavsky, Mike. Observing the User Experience: A Practitioner’s Guide to User Research. San Francisco, CA: Morgan Kaufmann Publishers, 2003.

6 Comments

I also think people should verify the validity of personas that are based only on qualitative research, by quantitative analytics measurement of quantitative data.

This is well-drafted article, which lets you know how personas can be used in documentation. Great job Arun and Niranjan.

Just a quick note. I think you have confusion about the distinction between qualitative and quantitative data. Qualitative data is data that measures qualities. Gender, for example, is qualitative; as is nationality, job type; whereas income would be quantitative´┐Żit’s a precise quantity. The frequencies of these can be summarized as quantitative, but when classifying data, you should focus on a single datum.

Check out a statistics resource rather than a UX resource for stats. (UX stats is generally poor and often incorrect.)

This information is very detailed and quality info. Thanks a lot.

p>But one suggestion: It would have been complete if you could have presented a sample or a case study document as a demo to see the live approach.

This information it very good and very easily understandable. But as Prasad Pachhe has said, if you would share some samples or a case study, that would be the cherry on the top. Anyway thanks for the good writing.

I’m in SEO and looking for the right way to integrate personas into my work. I loved this article. It was the most helpful I’ve read till now.

Join the Discussion

Asterisks (*) indicate required information.