Demographically biased personas hinders the understanding about the really important user behaviours, needs and expectations in the context of use. By dressing users in demographics and photos, personas make readers fill in with their own assumptions. If you want to accomplish intentional design – design that makes impact – it's about time you ditch the persona.
All of inUse courses here, visit Academy!
I started my career in the UX community long before the label “UX”. 1983 I started working as a developer, and ten years later I realized that I was a usability professional. At that time there were simply no educations to become that, so I succeeded by reading a lot of research papers and learning by testing pieces in my assignment, and discussing with the small number of peers there were in Sweden by that time. Remember, the internet was not yet there to help…
So, I lived and learned through the revolution of graphical interfaces, the PC, the web and now (finally!) the growing insight that business gain is nothing than a sum of usage occasions. If users succeed, the gain can be great. When users fail, the cost is immense.
I was intrigued by Alan Cooper's book “The Inmates is Running the Asylum” when it came in 1999. I just loved the title, since I actually trained to work in mental care before considering working with digital services. But most of all i liked it because of the content, where many struggles of a UX:er were brought into the light. At the time that I read the book I had finished a research project on how to help business to describe their needs in ways that could ensure business benefits. And started outlining the idea on Impact Mapping, that saw the public light in 2002.
I was taken by great surprise on the explosion of demographic based Personas, that came as a result of Coopers suggestion. I read the book as Personas where more of user behaviours than demographics. Up to today, I meet companies that describe their users by demographically biased personas, instead of clustering user behaviours and expectations.
During the years of my practice I experienced the danger of Personas. As they give a lot of demographic descriptions they actually hinders the understanding on the only important thing, namely user bahaviours, needs and expectations in the context of use. By dressing users in demographics and photos they make readers fill in with their own assumptions, based on their knowledge. This is an intrinsic capability of the human brain that helps us a lot in everyday life, but in this case it makes us see what is not there (WYSIATI). And that is really bad for doing intentional design.
To succeed with designing and building for impact the Persona must be finally ditched and replaced with something similar to what Indi Young refers to as “behavioral audience segment” or “thinking styles”. Description on what users do, need and the context for their use.
The discussion about Personas, have been around for some years now. I simply suggest that you start using the format described in the Impact Map, that correlates to Indi Youngs thinking styles, and in addition to that, adds certain amount of clarity and the strong opportunity to prioritize behaviours in respect to Business Impact.
The Impact Map refines the description into something we refer to as “users” or “behavioral patterns”. The impact map is centered (visually and logically) around the intended Business Impact that this (future or existing) service could bring, if designed right. Then the users are described by their behavior in their specific context of use and expectations for the solution. Or if you want to see it from a business perspective: the users are described as means to get the desired business impact. By making the description of use in this manner, it also opens up for another intrinsic part of the user description in an Impact Map, namely that users are prioritized, based on their contribution to the Business Impact. This is a very strong concept of the Impact Map, bringing lot of information to designers, developers and managers on what to spend money and time on.
The User in an Impact Map follows a pattern, This is an example (and a template for Impact Maps). Remember though, that what you see here is a polished result after research, analysis and decisions by business. To get there you will need to iterate.
A User/User Behavior is described as:
- A number, indicating priority. A User #1 is the most important when it comes to achieving intended Business Impact. This said, when the Business Impact is not set, it is not possible (or meaningful) to give users priority. The #1 is the most important, still the user #5 can be extremely important on achieving some aspects of the desired Business Impact. That said, the prioritization is not an easy task for business, but yes, it aligns the different ways to think about the new service. In other words it is a mean to avoid lengthy discussions _after_ having started the project.
The prioritization is done by the business, with help from UX strategists. The priority is made based on the contribution to the Business Impact. To set the numbering you weigh together three aspects: occurence in the population, activity and influence on others. And relative to the other defined user behaviours.
Prioritization is an important, and often difficult part of impact mapping, and forces business stakeholders to discuss and agree on a common view on scope and way forward. - A name, summarizing the behaviours and expectation that users show. The name is short, memorable, and easy to remember. Some examples of good names (from completely different products) are “The inexperienced help seeker”, “The focused”, “Harmony seeker” or “Need to solve this now”. The latest is actually a quote, that can either be used to give the name some life, or as the name itself. Names that gives negative connotations are avoided, since they makes you think negative, instead of innovating. At rare occasions the user behaviors cluster into professional roles, then you can perhaps use them as name. But, what I see is that thinking beyond job roles helps people to find shared behaviors that exists regardless of roles. “Sales Manager” is the behavior of “Business responsible” that could very likely (now or in the future service) be a behaviour of some sales representatives.
- A visualization that is never, say never, a photo of a single person. Photos tricks the brain to fill in with our own assumptions, and hinders us to take in the opportunity that this user behaviour gives us. Powerful visualizations explains the behaviour, or drivers, and could be sketchy, iconic or polished, whatever works in the business context. If you (by some reason) still want to use photos, see to it that it explains a situation where the behaviour reveals. If you (by some reason) still have people on the photos, see to it that they covers different age, gender, skin color, abilities etc. As you understand by now, the best is simple to avoid having photos with people. The same goes for iconic people, see to it that they are free from age, gender and skin color.
- A description explaining why, when and how this user behaviour reaches for this solution. Other attributes that is important for the solution and context is described e.g. the learning and communication style, or how they navigate. Any common attributes of interest in order to reach the Business Impact is also described e.g. what they value, and what they strive to achieve.
If you have data for your user behaviour description, use it. However, the description should be kept short in the Impact Map, but could have a longer description elsewhere.
The description is best done by describing a person in present tense, e.g. “Person that…… he/she ….. Name is often, but not always….He/she prefers... A good day is when….” - Examples, that points out where this user behavior usually is spotted. What you use to define examples varies, based on the context for analysis. If there already are market-based personas, you should use them as examples. You will then find that one user behaviour is revealed by many personas and one persona reveals several user behaviours. Job roles, and situations are two other sets of examples that are more common than personas. In some rare occations, (as in the example) the user behaviour appears in so many contexts, so that it is better to skip the examples.
- Design Challenge, one sentence that explains what the service must give to the user behaviour in order to ensure that he/she is successful and satisfied. The sentence is usually written in the form “Provide [type of content, type of functions and their capability ] in order to [what we want the user to feel, think or do]
- User Needs, what Cooper initially referred to as user goals, or a “job” (emotional, functional or social) in the jobs-to-be-done context. It is one sentence that starts “wants” when it is a user need and “must” when it is something that the user is hesitant or opposed to, but we must impose on him/her in order to succeed to reach the Business Impact. When the analysis is done, user needs usually narrows down to as few as 1 to 3, since you understand what really makes them tick, instead of describing what they said or what you observed.
A good format for user needs is “Wants to [adjective] achieve sth, in order to [the goal for the user]. Use the strength of adjective form so that it is obvious how strong the need is, eg easy, very easy or super easy. User needs are the means for defining what and how to test a solution, so that if something is to be achieved in a supereasy way, you know what to look for in a test.
By actively avoiding demographics, user descriptions are now fit for a deeper understanding of user needs. Also, when the description is part of an Impact Map, user behaviors are prioritized, and are means for testing business impact. This is groundbreaking, still easy to achieve if you have done your user research. So - finally ditch the Persona style, and do User behavior style!