e46 Personas are meant to be used, not just created

Personas are a widely used method, as they are seemingly easy to create and fit well into the image of a standardized design process. But as with any other tool, their creation needs to be driven by actual usage, otherwise, they will just add to the list of useless artefacts in a project’s documentation.

Photo by Steve Johnson on Unsplash

☕ Personas are meant to be used, not just created

I’ve seen some portfolios recently, where the designer shows personas as part of their process. They describe the creation of personas and display them as pretty-looking artefacts. But somehow these personas don’t impact the rest of the design process, they are just there as a sort of unrelated step before the fun part of the case study.

Part of the issue is how rigidly the design process is perceived (and taught), with personas as a mandatory step between user research and solution ideas. Of course, it might be just an issue of presentation — artefacts are easier to show in a portfolio, and describing process details in later steps is less visual than actually showing UI iterations. But if we take working on the experience seriously, who the user is needs to be a key point, and shine through the design process.

This got me thinking on what are the good practices of using personas in the design process.

Personas are a method to aggregate user research, create a shared understanding of who the users are, and align the team on a common target. Of course, personas are not the only way to describe the audience, but they are a great way to focus the discussion on the users.

In some sense, personas act as a shortcut in conversations throughout the product development process. For this, they need to be based on actual user research, and the team should be able to easily connect with them. There are some ways to do this, most obviously making their creation a team effort helps (so workshops), but actively taking care of them (iterating and promoting) is also important.

The easiest way to get started with using personas is just to start replacing each mention of “users” or “customers” with an actual persona name when designing and talking about problems and solutions. This immediately steers the personas towards being understood and useful, as whoever is in the discussion needs to understand clearly what the persona exactly describes. Using them consistently will also drive iterations to improve data and presentation to make them more useful within the design process (as it’s often the case with having or not having demographics), and clarifying others (like the context of use).

This approach is also a good way to showcase how personas had an impact on the design process, For example when describing solutions, instead of writing We wanted users to have an easy way to find books, it’s better to have We wanted Frequent Reader Fred to have an easy way to find books. This also highlights how and why certain design trade-offs were made.

There are three more places where I found personas to be especially useful, setting the goals for designing, coming up with better ideas, and making prioritization more deliberate.

For setting the goals for design, I’ve written about expressing the intent via a design brief earlier. Together with the goal, the key scenarios, and the principles, personas set the boundaries for the space to explore while designing. These provide a consistent statement to look at in the messy middle of the design process for the whole team.

In coming up with new and valuable ideas, personas provide context and narrative. Whether in a design studio or when generating answers to HMWs, thinking about somebody concretely increases empathy (by making it more personal) and helps to come up with more specifics while opening up broader solution spaces.

Generating ideas alone is not enough, we also need to make sure we focus on the right things first. There are many prioritization techniques, where specifying which groups of users are represented by a persona we target is helpful. This is where having a clear ranking for the set of personas helps, as it makes choices clearer, who the team focuses on first, second and so on.

Personas can be used beyond the immediate design process, for example during development and marketing.

Most agile frameworks have a format for user stories. These can be improved by substituting user with a specific persona, for example, As Frequent Reader Fred, I want to have an easy way to find books, so I learn easier about new books. This way the benefit is more closely tied to the actual user research aggregated in the persona, rather than something made up.

Product marketing people usually already think about their target audience and message. Having a persona aligns the product’s design with the marketing efforts by providing an easily understandable common intention. Even though the personas created by a designer don’t have all the useful information for a marketeer (like demographics for targeting), they still provide a good starting point and common foundation.

So how to get a team of designers to start with personas?

As with other similar efforts, there needs to be a clear problem to solve (for example teams not having a common picture of who they need to solve problems for), and personas need to fit with the already established ways of working. For example, unless there is already a practice of talking to customers, it will be very hard to create useful personas.

The other common difficulty I see in getting personas right is how efforts often stop with creating a first version. While getting to useful personas takes time in itself, additional time testing them also needs to be considered, such as updating the data and iterating on the structure and presentation.

Ultimately as with any other tool, personas need to be useful throughout the design process to make them sensible to create.

This is a post from my newsletter, 9am26, subscribe here:

🍪 Things to snack on

Tamara Adlin’s and John Pruitt’s The Essential Persona Lifecycle is a great book about using personas in general, and their role during the product design process in particular. Chapter 6 (Persona adulthood) goes into nice detail about how they would be used in all phases: plan, design, evaluate, and release.

🁓

Personas are helpful during ideation, and the initial exploration of the solution space, as they provide an anchor point to tie new ideas to. Scenario Mapping: Design Ideation Using Personas by Kim Salazar describes a workshop technique for this, centred around describing the problems a persona would be facing, through a simple narrative description of their activities.

🁓

One way personas are useful is that they create a common understanding among the team members. This helps in focusing and uniting beliefs and knowledge people have about the users. Jeff Gothelf has a really nice case in Using personas for executive alignment for not only creating personas but immediately putting them to use in a design studio.

🁓

Beware the Cut ‘n’ Paste Persona is both a thoughtful critique of personas and an interesting method for an alternative that ties more closely into the design process. Emanuela Cozzi and Lennart Overkamp describe some of the problems with most personas and offer a different approach, which they call dynamic selves, focused more on the context of users. These create patterns that highlight opportunity areas for design exploration.

🁓

Personas are also useful beyond the immediate design process, as they can be added to the usual user story format most agile teams use. Patrick Neeman’s Why I love user stories has some details about using them as a designer.