From all over the techniques and tools related to design process and User experience, only personas appears as a consistent common denominator, even in methods against the use of extensive “deliverables” as Lean UX. Most of the point of view agree in that the secret of a great user experiences strategy lies on this tool, even so the building process varies significantly.
Probably the most important reason to create personas is to set a common understand of the final user. So that a coherent strategy is defined that will result in a product/service that is user oriented and meet the user goals.
This post and the further related ones, came from a personal work aimed to define a guideline for the creation of personas in daily work. Actually the state of art about personas is so extensive, so vast that this post don’t pretend to say anything is not already out there, but I think you may find this structure and easy starting point.
In this first part I will make a general approach, we will see what is the starting point and the basic methodology and what are the main elements that are typically included in user personas. Later I will create different posts focused on the most critical and complex variables.
“Personas are archetypes built to identify our real users profile, needs, wants and expectations in order to design best possible experience for them”.
One starting points:
Remember User Personas is a design tool. As a tool is used for answers key questions that are made to drive design: What would %persona_name% do in this moment?. What would he need now? Do %persona_name% understand this?
The purpose is to put all stakeholders in to the user’s shoes (PO, PM, Developers, Designers, etc).
Origins of User Personas
Seems to be personas origins came from marketing field, as a tool designed by Angus Jenkinson to categorize customer segments beyond the traditional segmentation based on demographic and with the purpose to achieve a higher level of knowledge about customers daily life, needs and desires, he named this tool “CustomerPrints” (Check Jenkinson , A . ( 1993-1994 ) ‘Beyond segmentation’). Recommend you to read Jenkinson paper, include some interesting framework about the evolution of customer from a “class or ‘clan’ society to an individually created society” , and the switch from traditional segmentation into grouping (“people who share common characteristics” as an appropriate response to this change. At the same time, you could see how this principles are definitely the base of modern “personas”, as a bottom up approach, people based and requirement driven.
Parallel to Jenkinson work, Alan Cooper, creator of the Goal Directed Design I mention in other posts was working in a similar concept he name “User personas” and fully describe in his book “The Inmates Are Running the Asylum”. Personas are described as hypothetical archetypes of actual users, and are defined by their goals, as their goals are defined itself by the personas. The methodology introduced by Cooper starts with the investigation of the problem domain. And some of the guidelines described are:
Design for just one persona, and you will have greater success (The Primary persona, we could have more than one) .
Using “the user” as a design tool is a mistake. The expression is to brad and this vagueness causes many design failures. Hi name this issue the “elastic user” and the solution to this vagueness is the specification Personas represent.
When Donald Norman joined Apple in 1993, the team leading by Joy Mountford were already using something like personas. Personas is the primary tool for the User Centered Design approach defined by Donald Norman and dominant design process used today for Software development. In UCD process the User Personas are built based in different techniques as exhaustive observation and interviews.
Common points across all user personas methods:
Personas are ‘fictional’ characters. Even so, they are created based on real data and research around a problem domain, or a focus target.
In UCD the personas are created based in a previous research, but in Lean UX methods for example, personas are created originally based on assumptions (proto-personas) in a brainstorming session with the team, and further checked against actual real data (See Gothelf, Jeff. Lean UX. Applying Lean Principles to Improve User Experience. 2013).
A product should have the minimum number of personas, so we focus design and this may guarantee better success.
- Personas must answers three basic questions: what are the user needs, wants and limitations.
- In User Personas is more important to be precise than accurate. This means they must be strongly consistent to itself so they don’t crush during the development process (“It matters more that the persona is expressed with sufficient precision that it cannot wiggle under the pressure of development than it does that it be the right one“).
Main elements of a Persona:
If you make a quick search at google you could see million different layouts, at the moment to create my guideline I went through many of them and as result I resume some main elements I saw in common, listed below.
Personality elements: This is the more inconsistent between all the personas layout I have seen. Personality is a very complex variable and in most cases I only saw a vague collection of qualifying adjectives. I do extensive research here and I have come across a technique that allows you to give a more or less consistent categorization, based on the Myers-Briggs (MBTI) type indicators and the 5Factor Model (I will describe in detail in another post).
Expertise: Area that describes character expertise in relation to the domain (normally computers and internet proficiency level). I use here different variables depending on the product-focus.
Must Does / Must Never: This area is probably one of the most actionable. Resume what they expect and want (must do) and what frustrates him and annoys (must never).
Referents & Influences: Represent People, brands and product that influence his relation with internet, computers and other devices, software and app, etc. (This could change depending on the product/service domain)
Devices & Platforms: This module reflect devices and platforms with which the persona are familiar. (This could change depending on the product/service domain)
Used product/service related with the domain. Depending on the domain of the product/service could be for example: software/apps.
Archetype: This is a short denomination for the persona, that pretend resume them in a few words. Some time refers to personality characteristics, others define a relationship with the product-service.
Key Quotes: simulate a Persona comment. Pretends reflect behavior or persona attitude as user
Experience Goals: What are the users expectations and priorities when interact with the product/service or about the goal pursued?
Brand-Relationship. Persona relationship with the specific brand and the product.
Picture: The final touch for your persona will be a person picture that illustrate the personality and lifestyle your persona have.
- User type: I used as a quick categorization of user expertise using a four level scale.
Methodology for gathering each point:
A key point for successful personas and the most extensive work I made was trying to describe a methodology for fill-in each one of the persona elements, following a common method so they could be created for different products without inconsistencies.
How we define Personality?. How we measure expertise?…
I will describe each one of the methods in the further post “DIY User Personas”.
Finally, lets see how all this elements are presented in a persona layout:
*The original basis for this User Persona layout is a team-work, so thanks to Gerard Adell, Roger Espona and Ignacio Pastor
References and recommended reading:
Jenkinson , A . ( 1994 ) ‘Beyond segmentation’