Demographically biased personas hinder our ability to understand the really important user behaviours, needs and expectations in the context of use. By dressing users up with demographics and photos, personas cause readers to 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.
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 educational programs to become that, so I succeeded by reading a lot of research papers and learned by testing pieces in my assignment, and discussing with the small number of peers there were in Sweden at 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 more than the sum of successful 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 Are 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 of the struggles faced by UX:ers were brought into the light. At that time, I had finished a research project on how to help businesses describe their needs in ways that would ensure business benefits. It was then that I started outlining the idea of Impact Mapping, that saw the public light in 2002.
I was taken by great surprise at the explosion of demographic-based Personas resulting from Coopers suggestion. When I read the book, I thought of personas more as user behaviours than demographics. Even today I meet companies that describe their users by demographically biased personas, instead of clustering user behaviours and expectations.
Throughout my years of practice I experienced the danger of Personas. They give too much weight to demographic descriptions which actually hinders the understanding of the only important things: user behaviours, needs and expectations in the context of use. By dressing users up with demographics and photos they make readers fill in the blanks 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 makes us see what is not there (WYSIATI). That is really bad when doing intentional design.
To succeed with designing and building for impact, we must finally ditch the Persona and replace it with something similar to what Indi Young refers to as “behavioral audience segment” or “thinking styles”. In other words, descriptions of what users do, need and their context for use.
The discussion about Personas has been around for some years now. I simply suggest that you start using the format described by the Impact Map, which correlates to Indi Young’s “thinking styles” adds clarity and gives a 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, if designed right, is centered (visually and logically) around the intended Business Impact that this future or existing service could bring. Users are then described by their behavior in their specific context of use, as well as what expectations they have for a 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 describing the 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 aspect of the Impact Map provides a lot of guidance 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 #1 User is the most important when it comes to achieving the intended Business Impact. This said, when the Business Impact is not set, it is not possible (or meaningful) to prioritize users. Even though the #1 user is the most important, user #5 can be extremely important in achieving some aspects of the desired Business Impact. Prioritizing is not an easy task for a business, but yes, it aligns the different ways of thinking about the new service. In other words it is a means to avoid lengthy discussions _after_ having started the project. Prioritization is led by the business, with help from UX strategists, and is determined based on the contribution to the Business Impact. To set the numbering you weigh together three aspects: occurrence in the population, activity and influence on others. You then compare relative to the other defined user behaviours. Prioritization is an important, and often difficult part of impact mapping. It forces business stakeholders to discuss and agree on a common view of the 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 give negative connotations are avoided, since they make you think negatively, 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, an I mean never, a photo of a single person. Photos trick the brain into filling in with our own assumptions, hindering us from taking the opportunity that this user behaviour gives us. Powerful visualizations should explain the behaviour, or drivers, and could be sketchy, iconic or polished, whatever works in the business context. If you (for some reason) still want to use photos, see to it that it explains a situation where the behaviour reveals. If you (for some reason) still have people on the photos, see to it that they cover different age, gender, skin color, abilities etc. As you understand by now, the best is simply to avoid having photos with people. The same goes for icons of 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 are important for the solution and context are described (e.g. the learning and communication style, or how they navigate). Any common attributes of interest in order to reach the Business Impact are 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….”).
- (In the description, also give) Examples on where this user behavior usually is spotted. What you use to define examples is 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 occasions, (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,which are what Cooper initially referred to as user goals, or a “job” (emotional, functional or social) in the jobs-to-be-done context. It’s one sentence that starts with “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 reach the desired Business Impact. When the analysis is done, user needs usually narrow down to as few as 1 to 3. This is because instead of describing what they said or what you observed, you understand what really makes them tick. User needs should define the level of importance, so use adjective and adverbs for defining urgency. Knowing If something is supposed to be easy, very easy or super easy for the user to achieve is a great help to the team in charge of designing and testing.
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 thus gives solid ground for designing and testing value to users and ultimately, to businesses. This is groundbreaking, yet still easy to achieve if you have done your user research. So — finally ditch the Persona style, and adopt the User behavior style!
/Ingrid Domingues, co-founder of inUse and creator of Impact Mapping and Management
