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 vehicle a 65 year-old rural farm owner requires is a hell of a lot different than the vehicle a 25 year-old downtown urban professional requires. One might be a durable, dependable, and basic pickup truck. You know – something that can haul big stuff around and handle a variety of terrain, with no delicate parts to worry about. The other might be a two-door hatchback that’s great on gas and can fit into small spaces. Oh, and it needs Bluetooth capabilities for streaming podcasts. 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 websites, web apps, or mobile apps. 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.
Okay, you’ve taken step 1 and are armed with a digital project brief. 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 product 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 really understand and concisely communicate need-to-know information about the users of the digital product we’re building to designers, developers, comms, and other project stakeholders. 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.
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 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.
Often, the key stakeholders 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 stakeholders 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 stakeholders questions designed to pull out the information required to flesh out the provided persona template. 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!
If the actual users you’re building the digital product for are available, interview them. There’s no better resource. It’s like getting the milk straight from the cow! No wait, that’s gross. You know what we mean.
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:
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.
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.
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.
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:
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.
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 a content management experience that gives me enough control to publish content and generate leads without wasting time on layout or styling.”
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.”
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.
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 Content Manager at [Company], primarily responsible for all marketing copy and general content published to the corporate website. She’s a tech-savvy 22-year old; a creative personality, she is highly productive and gets satisfaction out of seeing her work out in the world, benefiting [Company]. She’s an outgoing, exuberant person who doesn’t hesitate to share her opinion, and while she has sufficient expertise in managing content and the web, it doesn’t quite extend into understanding the full development stack. Seeing as she’s the one who will be using the platform the site is built on, the intuitiveness of the CMS matters a lot to her.”
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 digital product can help them achieve. What do they want to be able to do when using the product?
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 generate 10 web leads a week via a consistent blog post publishing schedule”. The Needs required for that goal could be:
And so forth.
This section is pretty straightforward, and can help the design team be aware of the frustration points to ensure the product being designed improves on them. The persona frustrations can be very specific (“Making my blog post images render nicely on multiple display densities is time-consuming”) or general (“My boss wants me to put out three pieces of content a week 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 digital product itself.
Most user persona documents for a project have multiple personas within them. We usually end up with three to five 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.
If the project you’re undertaking is a website, and providing helpful information to your users is part of the project objectives, then Content Preferences is a beneficial piece to a user persona. Basically, we’re talking about user-focused content – not business-focused content. If you’re building a web app or a mobile app, this section will be less about content marketing and more about 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 at the bottom of this post. Save yourself some time!
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 information 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!