Never make your personas phony
You design for users and only then we can call artefact-making project a design when it is used by users. If it’s not useful (usable, utile, used) it’s an art. Not design.
Design is a method worked out in advance for achieving some objectives.
It means there are objectives (goals, aims, conditions).
There is a successful struggle (try, …)
There is a method (found in the struggle) — a solution.
And there is some work associated with this method. That means it has consumed some energy and didn’t come easy. It was a workout.
And there’s finally a scaleable recipient, someone who can honestly say: ‘I needed that’.
So that is what User Experience Design is all about: working out a method for achieving (user) objectives.
But how to describe that user, and what is its kind? We can’t design for each and every one, and surely we cannot design for a particular individual because we can miss an opportunity for successful design. We should agree on a kind of average, archetypical, model user. People are different, but if we focus on general traits in context of their goals execution, we could put them into several baskets basing on their shared traits. Personas exactly are names of these baskets. Personas are inherently an amalgamation, an average of similar attributes, variables, approaches and behaviour that we observe in our users. They are not the average user. They are spectral projection of customers groups, defined by their activities and interaction model with the product rather than their inherited qualities. The categorization is arbitrary. Less traits we check, broader edges of these personas will be.
Personas represent behavioural pattern
Personas are composite archetypes based on behaviour patterns uncovered during the course of our research, which are formalized for the purpose of informing the product design. Personas stand for our users, they are recipients of designed solutions, they help to ideate and test solutions by putting them into the scenario plot. They help align development team as well as explain decisions to stakeholders. Personas are basic tool of UX Design, and once defined they have to be credible, accepted by the team and approved by stakeholders. The design solution depends on how well-defined personas are.
Personas creation process
- First there is some hypothesis to be made. The collection of possible users and types is to be sketched at the very beginning. It’s rather vague and open-end group that we have a right to refine after interviews session has stared.
- The interview or contextual inquiry (if there is any testable, or at least similar solution on the market, or alternative ways of completing user goals) of subjects’ representatives from these groups.
- Variables should be defined before the first interview. Map observations to variables.
- Identify emerging behavioural patterns. Map observed values into clusters.
- Synthesize characteristics and match them with goals.
- Remove redundant personas. Reduce personas number.
- Define personas types.
- Keep personas live, adjust description if there are new patterns emerging. Broaden the understanding of your persona. Use the persona to visualize the design statement and requirements to the team. Use personas into test scenarios. Address your design decisions to your personas. Never let your personas to be forgotten.
Defining behavioural pattern
The data collected during interviews and user observation should allow for clustering several variables, it will likely represent a significant behavioural pattern that will form the basis of a persona. The design should address these variables - if only you don’t design a horoscope or biorhythm app — don’t go for zodiac sign or temperament type. Definitely don’t fake your personas. Don’t conjure and don’t make guessing. Don’t go too far for biography. Variables that you are seeking in your personas should bring a value to the design and the design should refer to them. Variables vary depending on project, but most likely you should observe:
- Activities. What the user does; frequency and volume. What is her behaviour, consecutive steps in course of interaction with software and her goals completion.
- Attitudes. How the user thinks about the product domain and technology. How she describes the process, what’s her mental model.
- Aptitudes. What education and training the user has; ability to learn.
- Motivations. Why the user is engaged in the product domain.
- Skills. User abilities related to the product domain and technology.
- Emotions. What is the user emotional state during the scenario execution, has it changed in course of action.
- Pain points and problems. What obstacles did a user encounter when executing her goals.
Fictional Personas (or permanent Hypothetical Persona): The fictional persona does not emerge from user research, it emerges from the experience of the UX design team. It requires the team to make assumptions based on their past interactions with the user base and products to deliver a picture. Fictional persona won’t let you to design a solution based on constraints; She won’t bend your design, she will simply adjust to it.
Get your Persona Mapping Template from miro here:
We repeat the same error every day in product development. We imagine a persona — let’s say his name is Ted. We give him attributes, like a family, a high-powered job, a suburban house, and two cars (see main image). Maybe he’s got a cat. Then we’ll have debates about what Ted would or wouldn’t like. “Can you really imagine that Ted would be ok with that product decision? From what I understand about Ted’s profile, I don’t think so.” But it’s challenging, because the more “human” we try to make Ted by adding specific personality traits and details about his habits, the more we unconsciously stereotype him.
Margaret P
Defining persona types
Let’s think about Chris, he has been skiing this morning, strayed the track and ended up somewhere. He is calling his friends. He has his fingertips frozen, he can’t control well the touchscreen with his fingers nor with his gloves.
There’s also Anthony. Anthony is 72. He can see quite well but with his glasses. To write a message is a strenuous job for him, he uses voice control.
There’s also Martha. She’s 19. She got blinded with tear gas while manifesting diversity and equal rights. She’s calling her friends which she parted in resulting turmoil.
And there’s also Jenny. Jenny is 53, she is sunbathing. She wants to call her nephew, departed for a beach stroll an hour ago. She is sun blinded.
All four users are different in age, temper, background and experience only have they in common voice controlled goals completion. Personas are defined in context of their goals. Here, it would be one persona, let say Jem, and one corresponding (voice)interface used to address one goal, dialling a contact.
Personas correspond to interface. Each primary persona has its own interface apart that facilitates her goals execution.
Prioritize personas
by Alan Cooper, Robert Reimann, David Cronin and Christopher Noessel.
- Primary. Primary personas are the main target of interface design. A product can have only one primary persona per interface, but it is possible for some products (especially enterprise products) to have multiple distinct interfaces, each targeted at a distinct primary persona. A primary persona will not be satisfied by a design targeted at any other persona in the set.
- Secondary. A secondary persona is mostly satisfied with the primary persona’s interface. However, it has specific additional needs that can be accommodated without upsetting the product’s ability to serve the primary persona. We do not always have a secondary persona. More than three or four secondary personas can be a sign that the proposed product’s scope may be too large and unfocused.
- Supplemental. Their needs are completely represented by a combination of primary and secondary personas and are completely satisfied by the solution we devise for. Any number of supplemental personas can be associated with an interface. Often political personas — the ones added to the cast to address stakeholder assumptions — become supplemental personas.
- Customer. Customer personas address the needs of customers, the buyer of the product, not the end-user.
- Served. These personas are not end-users but they are directly affected by the use of the product. A patient being treated by a radiation therapy machine is not a user of the machine’s interface, but she is very much served by a good interface. Served personas provide a way to track second-order social and physical ramifications of products.
- Negative. Negative personas (also sometimes called anti-personas ) are used to communicate to stakeholders and product team members that the product is not being built to serve specific types of users.
Focus the design for each interface on a single primary persona
Persona Description
Do include summarizing descriptions of all significant behaviour patterns in your narrative. Do not include excessive fictional descriptions. Include just enough detail to cover basic demographics and to weave the behaviour patterns into a story. Do not add levels of details to your behavioural descriptions that are not observed. Do not introduce solutions into your persona narrative. Rather, highlight pain points.
Defining goals
By identifying the logical connections between each cluster of interviewees’ behaviours, goals that caused those behaviours can be inferred.
Majority of useful goals for a persona are End goals.
Life goals are most useful for personas of consumer-oriented products, but they can also make sense for enterprise personas in transient job roles.
General experience goals such as “Don’t feel stupid” and “Don’t waste time” can be taken as implicit for almost any persona.
Read more aboiut user goals.
Bridging research-design gap
Once created personas will live all along the project stages. Personas can’t be separated from User Requirements. Every story developed should be told from the perspective of persona, as a means of imagining ideal user interactions. These stories or scenarios are essential to extract design requirements. These gathered requirements in turn are the base to define the product’s fundamental interaction framework. This framework is then filled in with ever-increasing amounts of design detail.
Narrative is the glue. Interaction design narratives share two significant characteristics with comic story-boards: plot and brevity. Scenarios are more akin to epics as described by agile methods. Remember that, whenever you refer, in the story, to “As a user…” you mean specific persona.
Persona-based scenarios
Scenarios are concise narrative descriptions of one or more personas using a product or service to achieve specific goals. They allow us to start our designs from a story describing an ideal experience from the persona’s perspective, focusing on people and how they think and behave, rather than on technology or business goals. This is perfectly aligned with agile scrum methodology of leaving the team room for finding the solution.
Types of scenarios for your personas
While learning from researches and user testing, we gradually add details to scenarios performed by our personas.
Context scenario
The context scenarios are created before any design sketching is performed. They are used to explore at a high level, how the product can best serve the needs of the personas.
Key path scenario
More specifically describing user interactions with the product and by introducing the design’s vocabulary. They focus on the most significant user interactions, always paying attention to how a persona uses the product to achieve its goals. These correspond to happy flows, and are responded to visually. They are also user-tested.
Validation scenarios
Test the design solution in a variety of situations. These scenarios tend to be less detailed and typically take the form of a number of what-if questions about the proposed solutions. These are edge and corner cases.
A persona spectrum is not a fake person. It’s an articulation of a specific human motivation and the ways it’s shared across multiple groups. It shows how that motivation can change depending on context.
Margaret P
Summary
- Base your personas on variables mapping from real users.
- Personas are spectral range of activities, attitudes, aptitudes, motivations, skills, emotions, pain points and problems groupped per goals execution.
- Prioritize personas.
- Surely you’ll need to weave soome narrative plot around your personas, but don’t fill them with too much fake bio what would make them too specific.
- Create scenarios around these personas.
- Use persoans to aling with your development team and stakeholders. Make them as probable as possible to make the team trust in them.
- Don’t forget your personas throughout design process.
Make sure to read Margaret P’s great insights, and understand her term: Persona Spectrum:
And insightful article from Jessica Sherratt
