This week I’ve been thinking about personas and how they are such a useful tool for technical writers that extends beyond their practical applications in marketing and UX design.

What are personas?

In case you’re not already familiar with what a persona is, Wikipedia comes to the rescue with this handy definition:

A persona… in user-centered design and marketing is a fictional character created to represent a user type that might use a site, brand, or product in a similar way. … A user persona is a representation of the goals and behavior of a hypothesized group of users. … Personas are useful in considering the goals, desires, and limitations of brand buyers and users in order to help to guide decisions about a service, product or interaction space such as features, interactions, and visual design of a website. Personas may also be used as part of a user-centered design process for designing software and are also considered a part of interaction design (IxD), having been used in industrial design and more recently for online marketing purposes.

When creating a persona, you typically define the persona’s demographics, background, goals, motivations, frustrations, and other relevant points of information about that type of customer.

Honestly, the concept of personas kind of blew my mind when I first learned about them. I was first introduced to the concept of personas as a new employee at SaltStack in 2019. Our UX designers created the core personas for our product shortly after I was hired as a way to assist our engineers with customer-centric, user story-driven product planning. Part of the reason it was so transformative for me was because it was my first time being part of a really well-developed and high-functioning product planning process that placed our customers at the center of everything we were trying to do.

But more importantly, SaltStack’s personas made it so easy for me to clearly identify which audience I was creating documentation for. I could think of them as distinct people who filled specific roles and used our product in specific ways and who needed certain information from the documentation in order to be successful. Since then, I’ve become a big believer in personas and see them as an indispensable tool when I’m trying to understand my audience.

I also want to credit my friend Ryan, who is one of the contributors to The Good Docs project, for expanding my understanding of personas. Ryan’s talk Emotional personas: writing for the human animal helped me realize that personas can also be a useful tool for developing deeper empathy for readers who approach documentation from different mindsets. Ryan advocates for creating documentation personas organized around particular emotions rather than a demographic cohort. I find myself thinking about this concept and his recommendations for making documentation fit these different emotional needs quite a bit. It informs many of my document design decisions now.

How personas help technical writers

So it was for that reason that last week when I sat down to create a set of policies and procedures for The Good Docs, I found that I needed to create personas first. I needed to better understand the key types of people who would interact with our processes on a deeper level. So, I discovered that I couldn’t even start writing until I had defined our project’s core personas. Even though it was a time-intensive process that took some time away from my primary writing task, I found it was necessary to get me into the best mindset for understanding who I was actually creating policies for.

With that in mind, I’ll share a few quick tips from my personal experience about how to use personas effectively in product planning and documentation design:

• Take personas seriously. Even though they are fictional people, personas are connected to real people that are ideally based on actual market research. I find that it helps me to get into the spirit to actually talk about them as though they are real people I am writing to and I’ll sometimes refer to them by name. For example, “Both IT Ivan and Sys Admin Scott will need to know how to configure this setting in order to successfully use this feature.”
• Encourage your team to refer to personas regularly to maintain a customer-centric mindset. The true power of personas comes from making an abstract, vague audience for your documentation into someone real who will be directly impacted by your work. When used the right way, personas can help your team develop a common understanding of exactly who your customer is, which helps you make more customer-driven decisions both in terms of the product and in terms of your documentation.
• Use them by name in your documentation user stories. The typical user story template is “As user X, I want to use feature Y to do task Z.” It really helps to write a user story with your personas in mind. “As Community Chloe, I want to complete a getting started tutorial to learn how to use Salt for the first time.”

When personas aren’t quite enough

That being said, I do want to acknowledge some of the limitations of personas. I agree with this statement by the Splunk documentation team in The Product is Docs:

At this point you might be saying to yourself that your UX or product team, or even the technical writers themselves, have a set of carefully-crafted personas to guide information development work. If that’s the case, great! Personas, especially when grounded in user and task analysis, are an excellent tool for documentarians. But a persona definition and an audience definition are not the same thing. …

[O]ur experience indicates that a useful audience definition works better than a persona for training new writers, applying techniques like learning objectives, guiding broader information design and development questions, and enabling customers to identify what content is relevant to them (25-26).

Like the folks at Splunk docs, I have found that personas get me started and probably get me even 65-75% of the way there in terms of understanding my audience well enough to create effective documentation. But a comprehensive audience analysis is needed to get me the rest of the way there.

One of the most transformative experiences I did as a writer was to take a day off from work last fall to talk to my friend Brad who was in the target profession I was writing documentation for: network engineers. I prepared for the meeting by reading a large introductory book about network engineering. I spent the whole day quizzing him for details about what network engineers know at various levels of their careers and what types of problems they’re trying to solve. We also filled in gaps in my knowledge that were still there after reading the introductory book. I bought him lunch to say thank you for that tremendous gift of his time and knowledge. That experience has given me a much better understanding of who I was writing for and what assumptions I could make about their prior knowledge and what common problems they needed to solve.

So, yes, personas won’t get you all the way there. You still need to buckle down and do your deeper homework because the level of knowledge you need to have about your knowledge is deeper than what a marketer or UX designer needs. But personas are the perfect place to start and can work in a pinch when you’re first starting out because they will always help you think about your audience in concrete terms.