The Ultimate Guide to Writing User Personas

Imagine you’re designing a vehicle.

There are countless decisions to make when starting that process. How many doors should it have? Should it be manual or automatic? Should it have a backup camera? Does highway mileage matter? What colours should it be available in? Even basic stuff: is it a truck, a van, a car, or a motorcycle?

The only way to begin making the right decisions in order to design a successful vehicle is to understand exactly who you’re making the vehicle for.

After all, the requirements for a vehicle for a 65-year-old rural farm owner are a lot different than that of a 25-year-old urban professional. One might be a heavy-duty pickup truck; the other, a two-door hatchback with Bluetooth capabilities. They’re both vehicles, but their users are completely different and warrant entirely different design choices.

The same analogy applies to the work we do in digital products, be they web apps, mobile apps, or entire software platforms. At the end of the day, we’re making digital products for actual people – and the success of these products depends on our ability to understand the end user, empathize with them, and design something that suits their needs.

User personas, when done properly, do exactly that – which is why they’re an important step of the digital project discovery phase.

What Are User Personas?

Okay, you’ve taken step 1 and are armed with a digital project brief for your web or mobile app. You’ve been intentional in outlining the project: the how, what, why, and when from a macro-level. The next step in your digital project discovery is to take that brief and go further into the who you’re making the application for – and we do that with user personas.

User personas are defined well by Wikipedia:

“A user persona is a representation of the goals and behavior of a hypothesized group of users. In most cases, personas are synthesized from data collected from interviews with users.”

That’s a solid way to define them. User personas are primarily written documents, designed to concisely communicate need-to-know information about the users of the digital product we’re building to designers, developers, comms, and other invested parties. The idea is that we can drill down to the key traits and goals that matter most to our core group of users and personify them within this document. Then we can use the personas to guide decision-making throughout the project in a user-centered fashion.

That last point is an important principle that shouldn’t be missed. There’s no point in making user personas if everyone isn’t in alignment with user-centered design as the project methodology. There needs to be true buy-in to the idea that we’re designing the optimal solution for our users – not for our own personal preferences. That’s how we avoid designing a teeny hatchback for a grizzled farmhand.

Doing the Research for User Personas

It’s cool that we understand what personas are and why we’d want to use them. It’s also neat to have a handy template (download below) that aids in the process of creating them. But the single most important part of the user persona process is getting effective and accurate information to actually put in them.

There are numerous methods for getting this information, and deeply held opinions on which methods are proper and which are worthless (after all, this IS the internet we’re talking about). That said, at the end of the day we’re often bound by what’s feasible – time, resources, and budget. All that fun stuff. So let’s explore a few methods of user research of varying effort / cost / effectiveness. Note that we’re just discussing attitudinal research for now; behavioural research for usability studies is another topic for another day.

Interview Primary Knowledge Holders

Often, the key decision-makers of a business – C-level execs, Marketing Managers, etc – have a reasonable amount of knowledge when it comes to their users. In a pinch, when end users simply aren’t available or budget doesn’t allow it, interviewing these people still carries value.

Ask the decision-makers who their top five users or user groups are (you can turn them into personas later on your own time). Write them down across the top of a whiteboard. Then, go vertically through each group and ask the decision-makers questions that will help you complete the persona template, which you can download below. This can be a straight-up question and answer exercise (“What’s the age range of this group?”), or it can be an interactive exercise of some kind (“Write down one goal for this user on a sticky note and place it on the whiteboard”).

Record the session, have someone take minutes, and/or take a photo of the whiteboard. Regardless of how you do it, make sure the information gleaned is captured in an effective manner. Then, translate it into user personas!

Interview Users in Person

If the actual users you’re building the digital product for are available, interview them. There’s no better resource.

Again, the methods of capturing the information are variable and dependent on what’s feasible to you – we’ve done everything from a casual conversation to recorded interviews to sitting with users for hours watching them work. The main takeaway is to ensure you really understand them and get the information you need to make the product a success. Ask them:

• What do you love about this current web app/mobile app?
• What do you hate about it?
• What do you wish the new version had?
• What are the five most common tasks you do day-to-day?

Again, use the user personas template we provide to steer your knowledge gathering. Make sure you understand their role and responsibilities, their goals, their needs when it comes to the product, their frustrations, and how and why they use the current tool. If you’re building a digital product to replace a paper-based process, make sure you understand what works in the paper process.

Send out a Survey

If actual users are not available to interview or the data sample is way too small, creating a short user survey and sending it out to targeted groups via email is a great way to supplement the information needed for effective user personas. Again, this assumes you have email access and permission to contact those users. Design your questions to capture the information needed to understand and create user personas, and do so in a way that’s efficient for the respondents to complete. You can use tools like SurveyMonkey, Typeform, or even good ol’ Google Forms to create the survey and work with the data you get back.

Multiple Sources of Information are Best

Given the limitations of budget, timeline, and resources, try to use all three methods of attitudinal research for optimal effectiveness where possible. The more perspectives you get, the easier it will be to create effective, well-rounded personas – personas that aren’t too heavily biased towards a singular opinion or data source.

Turning Research into Actual User Personas

Once you’ve gathered your user research in whatever fashion was feasible for the project, it’s time to translate the findings into actual concise, helpful user personas. Remember, we’re going to be using these documents to guide decision-making and conversations for the course of this project!

Just like digital project briefs, user personas don’t follow a hard-and-fast set of layout or content rules. However, there are a few key pieces of information that we’ve found handy to include. They’re described below, and we’ve also made a free user personas template for you to get started:

Name and Photo

Naming your personas is a simple way to have consistent communication (“I understand you think it’s important, but does it help Caitlin meet her objectives?”). That, combined with a photo, helps personalize the whole experience, too. Oh, and if you’re looking for some free stock photos to use for the personas, check out Pexels.

User Quote

If there’s one thing you want someone to remember from the user persona, it’s the user quote. Written from the persona’s point of view, it’s meant to encapsulate what matters most to them, or what their primary pain point is, in their voice. For example:

“I just want to complete a vehicle inspection quickly so I can get on with my deliveries.”

Another example might be:

“I need something that helps me manage the influx of job applications while I’m on-the-go so I can stay productive.”

Summary

The summary section encapsulates the basics: Age, Occupation, Location, and Values/Traits. While this information might seem superfluous at first glance, key information can be gleaned from it – especially when used within context of the rest of the document. For example, location can indicate proximity to or availability of high-speed WiFi, values and traits can guide user experience decisions or microcopy, and age/occupation can indicate level of experience in the field.

Narrative

The narrative is a handy way to write, in plain language, a snapshot of this persona. The intent is for the reader to leave this section feeling like they know this person a little bit. If you were to describe this person to a cohort – including information about their personality, worldview, skills, day-to-day responsibilities etc. – how would it sound? That’s what this section is for. Here’s an example:

“Caitlin is the Human Resources Manager at [Company], primarily responsible for triaging, directing, and categorizing all inbound applications that enter into the Company’s HRM. She’s a tech-savvy 32-year old; a creative personality, she is highly productive and gets satisfaction out of putting the right people in the right roles, benefiting [Company]. She’s an outgoing, exuberant person who doesn’t hesitate to share her opinion, and while she has sufficient expertise in HR software, it doesn’t quite extend into understanding the full development stack and guiding the development of a custom system. Seeing as she’s the one who will be using the platform that is being built, the intuitiveness of this new HRM matters a lot to her.”

Goals

The Goals section is contextual to the product you’re making for this persona. In other words, don’t include unrelated goals (“Go to 15 concerts this year” or “Do 100 pushups at once”); rather, enter the goals the persona has that your web or mobile app can help them achieve. What do they want to be able to do when using the software?

Needs

Needs can be thought of as important macro-level requirements specific to this persona. If Goals are what they want to be able to do, Needs are what the product has to support. For example, a Goal might be “to reduce call-back time to job applicants from 2 weeks to 1 week.” The Needs required for that goal could be:

• Ability for the system to alert the Manager when an applicant comes in
• Ability for the system to flag unaddressed applicants after 3 days
• Ability to notify the applicant of their application status through the system

And so forth.

Frustrations

This section is pretty straightforward, and can help the design team be aware of the frustration points to ensure the application being designed improves on them. The persona frustrations can be very specific (“Selecting multiple applicants at once for categorization”) or general (“My boss wants me to respond to every application within 24 hours but I don’t have the time”). The former is a specific solution that can be engineered for, while the latter can lead to a variety of potential solutions, from consultative ones to 3rd party solutions to engineered specifications within the application itself.

Key Differentiators

Most user persona documents for a project have multiple personas within them. We usually end up with three to five in our projects – and often, there are many similarities between each persona. The Key Differentiators section, then, is designed to highlight exactly that: what are the key pieces that make this persona different from that persona? Perhaps it’s technical aptitude. Perhaps it’s attitude/worldview. Perhaps it’s sway within their organization. Perhaps they spend a lot of time sharing content or reading reviews online. Regardless, it’s important to know and outline what makes each persona different.

Content Preferences

If you’re building a web app or a mobile app, this section will not be about content marketing – it should touch on helpful task-focused content: frequently asked questions, how-tos, and more. Ask yourself: when it comes to this product, what does this persona want to learn about?

All of these sections, with example placeholder content, are a part of the free user persona template document you can download via the form above. Save yourself some time!

Using Personas Going Forward

Once you’ve authored the user personas – and hopefully vetted, edited, and revised them with other project members in order to make them as accurate as possible – you’re done! Well, done with this phase of a digital project discovery anyways. But you’re not actually done with user personas.

Remember, user personas are about consolidating information required to continue moving the project in the right direction. All the answers don’t need to be in a user persona. But the information contained within the personas should help find those answers in the following stages of the project.

This means that, going forward, you’ll ideally use user personas at every stage in the project process. The next step in a proper digital project discovery is learning how to create user stories – user personas will guide those. After that, it’s translating user stories into project requirements – yep, user personas guide those too.

Whether we’re talking about application architecture & user journeys, prototyping, or reviewing work in project progress meetings, user personas should be in hand and steering each of those pieces of work and conversations, too. After all, there’s no point in doing all of this thinking work and then forgetting about it entirely. Researching, creating, revising, and using user personas going forward will move you down the path, step by step, to finding the right answers for the successful execution of your digital product.

Once you’re done with that, move on to the next article in the series: understanding and creating user stories!