When I shifted my career from UI to UX design, the very first thing I’ve learned about was Persona. And I immediately liked the idea of having one, because in the past I saw products fail due to misalignment with customer needs, I saw product teams do not agree on what a customer “need” is, and Persona seemed to be a great tool to prevent this. It is beneficial to think of personas and present them as an alignment tool rather than a research deliverable. 

I’ve read all possible books about building the Persona, but what was missing for me is practical information about what I should do to make it work. When I searched for “Persona Template” in Google, it gave me a set of very similar results, so I thought this is something I should start with and I tried to fit my research into these templates.

So I took one of these templates and worked hard to construct my Personas this way. I didn’t have a lot of success with trying to adopt these in my teams and as a designer I was demotivated with using Personas and then abandoned Personas for years, experimenting with other frameworks. 

Sometimes Personas Are Too Personal

Later I came back to designing Personas and one thing that I’ve realized that “impersonating” results of my research doesn’t help in any way and could be misleading. I work in the Enterprise IT space and if I choose a photo/image for each of my Personas the whole set will look like that (see below). Using fictional images and names without a purpose forces other team members to memorize them and this on its own creates a barrier in adopting Persona. 

Image Credit: Airbus

Alan Cooper in his book “About Face” says that “Personas are segmented along ranges of usage behavior, not demographics or buying behavior”.

For the consumer products however using visuals when constructing personas makes more sense, and not just because of the demographic (which can be a reasonable differentiator on its own), but also because of the environment where the products are used in.

Image Credit: Plantronics and BBtalkin. 

What Makes a Good Persona

Personas are not a one-size-fits-all tool. They should be used with a specific, well-defined goal in mind. For Personas to be useful, the data captured in a Persona should reflect the goal for that Persona and the scope of work it is meant to impact. (NNgroup)

The goals can be:

  • Understanding who your users are,
  • Increasing awareness of Personas in your organization, 
  • Team alignment on common goals, 
  • Discovery of segments of customers which needs / pains are unmet,
  • Backlog prioritization, 
  • User base segmentation, 
  • Etc. 

Persona creation process takes time and should be based on the actual research data and not on what we think we know about similar archetypes/jobs. Persona will change over time if product keeps changing and building one is not a one-time effort, but rather a continuous process.

Jobs-To-Be-Done

Using “Jobs-To-Be-Done” helped me to make my work research functional, and my research outcomes finally were adopted by the teams. Fantastic video explaining the value of Jobs-To-Be-Done by Clay Christensen is below. 

An example of a Jobs-To-Be-Done template is below. 

Image Credit Tony Ulwick 

What was always missing for me in the Jobs-To-Be-Done framework, that it’s not focused around the actual user’s goals and pains, so product thinking becomes very functional, but not user-centric.  

My Persona Template

I found it helpful to adopt some practices from “Jobs-To-Be-Done” framework when I build Personas. So I use the following principles. Personas should be: 

  • Concise
  • Based on the facts 
  • Include information that helps to drive design/product decisions 
  • Functional 
  • Presenting user Goals and Pain Points 

A good example of product Personas is provided below. 

Image Credit Enisa. 

So I’ve created a Persona template (and it is connected to the actual research artifacts in my Airtable). 

So the template above contains of: 

  1. Persona. I like to use “Role” instead of a fictional person name, because it reduces cognitive load and makes the document transparent.  
  2. Journey / Sub Product. Same persona can be primary in Journey A and secondary in Journey B.
  3. Primary / Secondary. The number of primary personas should be as little as possible. 
  4. Description. Facts that help to describe a certain archetype.
  5. Contributions. Is taken from the “Jobs-To-Be-Done” framework and helps to describe their activity with a product. 
  6. Goals / Needs. Actual Goals that your users share or are observed by researcher. 
  7. Challenges / Pain Points. Actual user pain points that your users share or are observed by researcher.
  8. People. This connects straight to my Airtable bases and lists all interviewees who belong to this Persona type.
  9. Notes. Any other related information (user’s actual job titles for example).

Please let me know in comments what do you think about my Persona template and what Persona goals do you set in your organization.