top of page
Writer's pictureCharles Edge

User Personas

A persona is an archetype of a group of users whose characteristics represent those of a larger group of users. Those characteristics can include jobs, attitudes, backgrounds, behavior patterns, skills, goals, and even details like where they typically work.

We often start with a template of what a persona is and often create fill in that template based on users we think of as typical of those that use a given product or service. We might even include real quotes from those people. The persona is an important aspect of creating, designing, marketing, and selling. In fact, in some organizations each of those functions might use a different persona tailored to their needs. But here, we’re going to create one that can be used for multiple use cases, a common step in a small team.


Parts of a Persona

Personas can be as simple as an index card or a full-on dossier of a user. Therefore, they can have a lot of components. We’ll start with some basic insights into motivations. Here, it’s important to define why the user might want to user our product. This guides conversations about buying patterns, how we design products to help the people we describe, and why they might keep coming to us to help solve a given problem. Let’s start with some basic questions that define the persona in the context of our product:

  • Who is the user? Feel free to include the average age, where they live, and what they do. For example, let’s say that our software is targeting advertising buyers from agencies, this might be “Advertising buyer at a large agency.”

  • What is their goal? Here, we look at what their larger goals are, how our product impacts those goals, what job they are looking to accomplish, and so how the product fits into their lives. The more succinctly we can define the problem they are trying to solve, the better. For example, our ad buyer might be looking to “show customer ROI from ad purchases.”

  • What’s keeping them from that goal? This is where we look at the solution our product provides and how it makes their lives better. Don’t forget, software is often all about making people more productive, increasing quality of life, and/or providing more telemetry into areas where people can gain insight from additional information (or with machine learning where we can provide insight on their behalf). To continue on with the ad buyer example, “hates spending hours per day entering ad responses and clicks into Excel.”

If we can answer these questions, we can more effectively build products that actually help real people accomplish goals they define, rather than the ones we assume on their behalf. In the above example, we might be able to develop tooling that pulls in data from a number of sources to help our ad buyer accomplish what once took hours per day in seconds.


A Little Deeper with Surveys

Now we just need to figure out what might keep them from buying the product now that we’ve managed to save them so much time (and frustration) so they can spend more time thinking about how to better leverage those ad dollars! To help us get there, we can develop a quick survey to send to ad buyers. Some example questions for this kind of buyer:

  • Title?

  • How big is your company?

  • How do you describe your job?

  • On average, how much time do you spend every day on data entry?

  • What tools do you use to help with the process today?

  • What other tasks do you do with that data once you have it?

  • What other tasks do you struggle with?

  • What do you enjoy doing when you’re not at work?

  • How can we make our product better?

Notice that most of this information is qualitative in nature. Some quantitative demographic data helps us develop good products, but one of the most dangerous things we do with data is tell ourselves what we want to hear. What we’re looking for in all of this is key insights that help us build better products. That means looking for patterns in the feedback we’re getting, and where our vision or assessments match or diverge.


Templates

At this point, we’ve laid out the three most basic aspects of a persona and a few questions we can ask to gain more insight, validate our thoughts, and look for trends in pain points. We also know from plenty of online tools about what each position description makes, about how much time we can save them (if we’re building productivity tooling), and so we can look at one of the ways to do pricing there. Value comes in a lot of different flavors so be sure to see the section on pricing for more. But in general we have a good starting place to see trends and build a persona (or three).


We’ll base our first persona on a template found online ( https://krypted.com/uncategorized/simple-persona-template/ ) and use it to take a few of the insights we gleaned and create a composite user out of those we were able to glean insights from. The image at the beginning of this article takes what we know about the people we serve so far and puts it into what could be printed and taped to walls or desks.


The personas help explain the people who use our products to new hires, help us frame up when we’re building a feature for Jill, or for the inevitable persona of (we hope) Jill as the boss. As we develop these, there are a few important things to keep in mind:

  • Start small. There are tons of great persona templates out there (ones that pur ours to shame). But start with a small amount of information and work more in later. After all, there’s no shortage of other things to do! Keep in mind, unless a single sheet is meant for different teams with different goals (e.g. sales persona, marketing persona, etc) then each should be one page or less, with plenty of white space.

  • Base the persona on a real person. This allows us to put much more information about the people we’re working with and appeal to them. The names can (and probably should) change, as can the photos.

  • Don’t over-index on a real human. The Pareto Principle is important here - we want to represent 80% of our users in a given cohort. We once created a persona called Josh, based on a real person named Josh. Every time we had a question about Josh we’d go ask the real Josh. Instead we should have been surveying users. Start with a real person and tweak it as we understand users better.

  • Personas are more than demographics. One mistake made by a lot of people is to put a lot of quantifiable information about the customers we serve in personas. We should be looking to quantifiably measure how we help. But personas are deeper and more personal. Thus the name.

  • Don’t make assumptions. We have to avoid our own bias. We do this by being open, listening, and asking simple and open-ended questions to real users. If we don’t do this we risk making mistakes when we had the chance to avoid them and worse, doubling down on what we think we know. We have to keep an open mind and look for insights, not just what we want to hear.

Ultimately, the personas we start with will likely end up in the garbage. As we hire people with “User Experience” in their title, they’ll likely skoff at our early examples. But it’s important to start with these, early in the life of a company. The above template could be filled out in less than ten minutes and as three seems to be a great starting point for personas, making three over a nice glass of wine is a great way to spend a little time letting the creative juices flow.


Now that we understand personas, let’s move into more UX Research with keeping them, and other things we assume we know on the behalf of our users, up-to-date by continually updating them.



170 views0 comments

Recent Posts

See All

コメント


bottom of page