Personas

Personas are a representation of the various target end user segments. When designing solutions, it's very natural to to fall into the trap of designing for oneself. The persona is meant to act as a reminder of who you're designing the solution for.

Personas are fictional characters which represent key types of the target user groups, these segments or user groups are discovered through research. This research would ideally be supported by data analytics, or it could be through direct observation if data is unavailable or potentially not reliable, and of course you can always fall back on indirect observation.

Regardless of research methodology, for a persona to be valuable, it must be data driven. If a persona is not supported by data, then it is at best a waste of time, and at worst a dangerous artefact which could lead your design team astray.

Though the actual persona is a fictitious representation of a user group, nothing about the persona is fictitious. Each persona is an amalgamation of factual data which represents that particular user segment. I bold factual data, because there is a trend for personas to be filled with fictitious bullshit; unless a segments golfing hobby has some relevance to the design challenge at hand and can be backed by data, it does not belong in a persona. (this is not to say that insights cannot be gathered from such an observation, however the observation is not an insight)

All data within a persona must be informative, this data should help designers, now and in the future solve their design challenges: creating a persona such as "Dave is a base jumper" or "Paul enjoys knitting" are of little value to the designer, instead the researcher should phrase these as insights into the personas such as "Dave is a risk taker" or "Paul is a homebody"; again these statements are an amalgamation of hopefully hundreds of real users:

• Sally enjoys street racing
• Frank is a base jumper
• Mike loves racing motorcycles
• Kelly spends her evening training MMA

These could be amalgamated to Dave the Persona as "Dave is an adrenaline junkie, who loves taking risks and needs exciting stimulation ."

One way to the persona

To create value added, data driven personas, the following is a completely valid and my preferred way of persona creation.

1. Identify Figure out who your target adience is, who could potentially gain from your solution, product, service, etc. understand the segments, leverage data, insights, observations to identify these user segments.
2. Define what you want to learn about your segments:
• Demographics: what data represents this person
• Goals: what does this person want to accomplish
• Motivations: what drives this person to accomplish their goal
• Behaviours: how do they act before, during, and after they pursue their goals
• Context: what is the environment around them, how does it help or hinder?
3. Interview: conduct the actual interviews to collect the data needed about your users. each persona should ideally have 100s of interviewees, if your user base is 10 people, then just interview them all and don't bother with personas. 
4. Correlate your findings. Logically group the data collected, then generate your personas from those grouping. remember you may not have a one to one segment to persona mapping, some segments may have several personas.
5. Iterate: just as your user's change, your personas will evolve, constantly interviewing and revising your personas are a good way to ensure that they will provide value long term.

Characteristics of personas

• Based on data: they are not a guess, user types identified through UX research.
• Embody the user: their goals, traits, behaviours, and the context that can influence how and if the solution will be used.  
• Represent distinct classes of users: Projects will have various types of users, from passive to power users to administrators, to interested parties, and so on. Personas should represent these variants or segments.

Elements of a Persona

• Demographics: general information about the user
• Age: how old they are, this can be generational.
• Occupation: what is their role 
• Location: where in the world are they (culture, language, village vs town vs city )
• Life Stage: marital status, family status, career status
• Technological literacy: High/Med/Low
  
  
• Goals & Motivators: things that drive the user to use the system or may act as barriers
• want to socialize for a social application
• want to meet romantic interest for dating app
• want to track fitness for fitness enthusiast 
• doesn't want to waste time for game
• doesn't like sharing personal information for social application
• doesn't care about fitness for couch potato
  
  
• Behaviours: routines or Behaviours that create opportunities or barriers for use of application
• working 9 to 5; can't watch live sporting events
• lives in country side with low bandwidth: preventing streaming of video
• uses public transit for travel: enables use of transit app
  
  
• Context: Living and working environment and other aspects of physical and social context that may be relevant to technology use.
• Lives in big city with lots of takeout options: opportunity for helping users find their preference
• Has physical handicap: help users find accessible places to go and things to do
• Dietary constraints: help users find a place to eat.

thus you'll have different values for each section of a persona; the question to ask yourself when deciding what goes into the persona is "will this information help me?" does the information tell me something valuable about the persona, a way to identify the user, understand what will drive them to use the solution or pull them away from it. Understanding the obstacles is just as important as the motivators. There is no hard and fast rule on what elements make up a persona, it's your persona, whatever you deem as informative and beneficial should be part of the persona, the above are simply common base elements, if they makes sense for you keep them, if not take them out and if you need other elements, add them.

Benefits of a Persona

• Summarize research data into the target audience
• Mental shortcut for design considerations 
• will persona A be capable of doing this
• would persona B want to do this
• facilitate discussion on who the target users are
• ensure that designers and stakeholder are on the same page as to who the system is for.
• Easy to understand for non designers
• Prevent designers from designing for themselves.
• Prevent the "Elastic user" fallacy
• Create concrete bounds to prevent design creep  

Personas should

• Personas are used as a constant reminder:
• "this is who I'm designing for, will this work for them?"
• Personas should feel like real people
• Personas should focus on commonalities and not idiosyncratic characteristics,
• Personas should embody you're average types, don't worry about the outliers focus on the "average Joes" of your solution.