The usefulness of persona’s in defining and designing interactive products has become more widely accepted in the last few years, but lack of published information has, unfortunately, left room for a lot of misconceptions about how personas are created, and about what information actually comprises a persona. In this article I hope to highlight a few essential points and describe the process of creating a persona.
What is a Persona?
A Persona is goal oriented. Goals are the reasons users perform tasks. Tasks change as technology changes but the underlying goals remain stable. Users may have a variety of kinds of goals. Tasks change as technology changes. But goals have the pleasant property of remaining very stable. That is a reason why designing for tasks doesn’t always suits, but designing for goals always does.
Persona’s represent prototypical users and embodies their distinctive goals, behaviors and characteristics that are relevant in regard to the developed product. Personae are developed based on qualitative information about the users of a system.
The goal is to develop a precise description of your user(s) and what she/he wishes to accomplish. A good persona will enable you to build a product which solves a real problem and that people love. A persona concentrates on insights around:
- What motivates the users?
- Why are they really using the system?
- What are they really trying to accomplish?
What is it not?
Personae are not quantitative audiences segmentations:
Those target audience’s concentrates on sales and/or marketing relevant information that are based on demographic, revenue data or distribution channels. Whereas personae rather represent design relevant aspects and are purely based on goals and behaviors. Personae are no market segments that separate users into audience buckets that share random value attributes - as for example, users’ that spent a certain amount of dollar on your platform. The attributes of a design or usability personae however doesn’t provide segmentation. Its purpose is rather to mirror the needs of an audience group and focus on the interaction with the product. The marketing persona shed light on the sales process, whereas the design persona shed light on the development process.
A Persona is not a real person:
It’s an archetype, which allows describing a group of people with common goals, behaviors and considerations. Creating a persona based on just one person will focus on individual idiosyncrasies, which will not lead to a widely usable system.
A Persona is not a decision maker:
It is tempting to design for the person making the buying decision but they are usually not the person (people) that will be ultimately using the application. Managers don't always understand the details of how work really gets done which is critical to a good persona. However; this role may be critical for an organization to determine whether to use the system and to what extends. Therefore I tend to evaluate a Non-Persona for those types of non-active customers. Ultimately you won’t design features according to their needs. But it helps to draw the bigger picture of how organizations work and users collaborate.
So, what is a Design Persona then for?
The whole point of creating personas is to get past our personal opinions and presuppositions to understand what users truly need. If we invent fictitious model users and call them persona, we’ll just have the same old problems with the development process packaged up in a new way.
As a tool, purely focused on the user perspective, it helps to prevent self-referential design decisions. It helps to bring the cross-functional product team onto the same page and ideate around well-targeted design decisions that ultimately lead into higher efficiency. Personae allow a product team to focus consciously on RELEVANT user characteristics. It is also an important tool to plan upon further usability activities.
How can my team use a Persona?
The persona is a simple and powerful tool. As always with simple tools - they must be applied with some sophistication. The sophistication comes from how we determine and use the precise user description that we call Persona. In order to build a better product, the persona will be used in conjunction with business goals and good design principles to guide design solutions. The actual user is still a valuable resource, and we devote considerable attention to him/her, but we never let the user directly affect the solution. You will find that the facilities that please some users will interfere with the enjoyment and satisfaction of others. Trying to please too many different points of view can kill an otherwise good product.
How can I build a Persona?
Personas are based primarily on ethnographic user data. Ethnographic techniques are valuable because they assume that an interview subject's attitudes and behaviors are so habitual as to be unconscious. Rather than asking users what they want, it is more effective to focus on what users do, what frustrates them, and what gives them satisfaction. By combining interview techniques with direct observation - preferably in the actual usage context - a lot of data can be gathered very quickly. Observation during field studies also helps minimize dependence on users' self-reported behavior, which is often inaccurate.
A dozen hour-long non-directing interviews are usually sufficient for defining a simple consumer product, though it can take several dozen for a complex enterprise application. You'll know you can stop interviewing when you can predict how each user will respond; this means patterns are beginning to emerge. If you have the time and budget, you can verify your findings with quantitative surveys or other techniques, but these cannot replace direct observation
However, practicing continuous design research in little chunks and validate and update or refine existing personas is a practical and useful approach to validate insights while working on other things.
Step 1: Hypothesis
Gather all existing information about user to create a hypothetical user profile. In our case we
created activity based audience segments that would help to screen research participants based on what they actually do. So we would ensure to ask the right person the right question.
We conducted a affinity exercises within a team of dedicated internal user advocates. These folks provided, aside from great commitment to the product, either outstanding empathy for our customers and their motivations or/and a grounded knowledge and understanding how our customer organizations work through earlier conversations or real life working experience in similar organizations.
Step 2: Screening & Recruiting
In close cooperation with stakeholders and decision maker I specify the audience segments that are of most interest. It has to become clear who these people should exactly be and how many of them do we want to talk to. Participant recruiting criteria for enterprise products would be defined and prioritized on both levels, the organization they work for as well as the activities and responsibilities of their business roles. The identified criteria will be formulated into screening questions that will help to qualify and identify the right participant during a screening process. Don’t underestimate this phase of the process! Screening, Recruiting and Scheduling the right participant is vital to gather truly valuable insights and it is a time consuming process.
Step 3: Interviews / Contextual Inquiries
Personae will be created based on ethnographic research. The qualitative data will be gathered during non-directed interviews. In close cooperation with internal stakeholders I gathered a catalog of questions that would be prioritized by decision makers to ensure that insights can be gathered accordingly. It is recommended to interview at least a few candidates per segment. The most valuable insights can be gathered during a contextual inquiry, the interviewer is visiting the user in their field and observes or shadows the user to gather insights on how user complete their tasks under real life circumstances. When not conducting evaluative research, where you don’t need to see how people behave when interacting with a certain tool, then an phone interview is just fine.
Step 4: Analysis
Design research is no market research. While the lather tend to summarize a list of facts and the amount of their appearance, design research aims for a rather psychological analysis of humans mental models. Therefore all gathered data will be combed for tasks in order to cluster and identify patterns (behavioral, thinking, doing) between all interviewees. The process of analyzing the transcripts is powerful but also painful. It is an intense period of work. I take those analyses into a 2-day workshop with stakeholders and interview observers or note takers to lead the evaluation process in form of an Affinity Diagram exercise. During this process the team will analyze users behaviors and activities in order to evaluate their goals and identify commonalities. The identified patterns will be described as detailed as possible and result in a Persona. Further out comings of this same type of data could be a Mental Model, as a basis to identify gaps and ideate around new solutions that support your users needs.