Mindset over matter: a new design trick for your toolbox, part one

Part 1: The trouble with Personas

«Cool, but can you make Personas?»

The scene was not unusual. At the time, we were working with a large European bank to create digital services that would simplify, and demystify, the home purchasing process. We had walked in with our research properly analysed. We had extracted insights that we considered powerful, actionable, and strongly rooted in a meticulous process. We were ready to address the challenges ahead and we were convinced of being on the right track to defining a competitive and well-designed service.

And yet, the reaction to our findings was lukewarm. Not because the results of the research were unsurprising, or uninspiring, but because we’d failed to deliver them in the format of Personas. But as familiar and reassuring they were to the stakeholders in this story, we had professionally distanced ourselves from Personas for a long time.

Welcome to yet another overly articulated opinion piece about Personas. It’s a rendition of the personal and professional journey of challenging our own biases towards a design tool we learned to use before we learned to question it, and of defining a new tool that, in this and other contexts, serves us better.

Ok, but why do we dislike Personas so much?

Personas, introduced by Alan Cooper in 1983 and refined over the years, are an important part of the “toolbox” most designers are taught to apply. They are a method of customer segmentation that is supposed to condense qualitative research into archetypal users of a product or a service, with a focus on needs, experiences, behaviours, and goals, and an added sprinkle of demographic profiling and storytelling to make them come to life. The purpose of Personas is to make the research relatable, easy to communicate, digest, reference, and apply to product and service development. Depending on who creates them and what they are going to be used for, Personas take different shapes and are described at different levels of granularity. Nevertheless, each Persona has a name, a gender, an age, an occupation, lives somewhere more or less specific, has wants and needs, and maybe even a dog.

Just to get one thing out of the way, our issue with Personas is not with how they have evolved, or how they are misused. It’s the methodology itself in its original form that, we think, is insufficient — and even problematic — for tackling the challenges that design has grown to face.

The core issue we have with it is that Personas, as static and unrealistic descriptions of non-existing individuals, easily become vectors for bias.

Shopping at Walmart or using a smartphone become signifiers of class status and gender. Names point to ethnicity. Pictures can imply truly anything: one can find a stock photo to support practically any bias and stereotype there is. These images become snapshots that, when paired with this imaginary person frozen in a moment of time, become immutable and immune to change. Jess will always live with roommates, love sports, work as a bartender, and struggle with finances.

How Personas build in active and/or passive bias

Bias is not just active, piling up details that depict a stereotype, but also passive. Personas quickly become an exclusionary tool. Once given a profile, we build on it and contextualise it based on our reality and experience. We create connections that are familiar to us. So unless specified, our Personas won’t reflect the diversity of experience across race, class, gender, sexual orientation and geography. They won’t be in a wheelchair, or identify as non-binary, or be in a non-monogamous relationship. On the flip side, an over-defined Persona ends up listing details that might be irrelevant to the task at hand and will often turn into an artificial exercise of balancing bias.

We are human. Even when we have the strictest approach to research and analysis, we still inject our own biases and interpretations into it. We fill in the blanks based on our own experience or belief systems, and Personas end up carrying these throughout the product development, thus confirming existing bias within the organisation.

While Personas were fantastic in promoting a user-centered approach when they were introduced, in the context of a discipline such as design that constantly evolves and redefines itself, they’ve become antiquated. Those who use them enthusiastically (many of us), often bounce off criticism by inviting the Personas-skeptic designers to apply a more orthodox approach to creating them, following the methodology as it was conceived and described by Cooper himself. But our discipline is all about change, about observation, adaptation, invention, self-reflection, and iteration. Why is this method, out of everything we make new and reinvent, so untouchable? And is it still the right tool for what we need to design now?

At the same time, Personas spread across sectors, roles, and organisations. Government services use Personas. Banks use Personas. Publishers use Personas. The method has changed and adapted to different needs, constrains, and demands. The defined Personas, whether the result of a thorough research and analysis, or a summary of quickly overlapping assumptions and data, are often reused across multiple projects and with different goals, giving the organisation the impression of being user-centered.

Challenging the tools

After our initial reaction of rejecting Personas altogether — insisting that our synthesis of the research into insights, user needs, and design principles was more than enough for getting a nuanced understanding of what we had to do in order to move towards — we decided to approach it as any other design brief: that is, challenge it. This is standard procedure for every time we start a project: approach critically, ask why, challenge, ideate, iterate. When we are asked to make an app, we advocate for taking the time to investigate whether users actually need an app. Why would it be any different for the methods and tools we use for making that app?

So we started unpacking the request, trying to identify which questions or problems each Persona was originally trying to address. Why did the project and the team need Personas? How would they be used? What kind of decision-making processes and artifacts would they end up supporting?

Business analysts and product owners needed a segmentation of how users would relate to the product, something that would help them frame the vision towards the wider organisation and get long-term support. Developers needed visibility on the reasons behind design choices, and a purpose to work towards.

And we, as designers, needed to understand and frame the triggers for big decisions and how users grow within a journey. What makes them feel comfortable, nervous, ambitious or cautious in their choices? What gains their trust, and what loses it?

None of these needs required a face, a name, or a backstory…

The elements of Personas that would give us answers were not dependent or reliant on the whole package, and we desperately needed to make sure that whatever we produced to support this process would not be static, but rather force a reflection on the mutability of how users relate to complex subjects or life experiences.

And that, in short, is how we came up with Mindsets. Stay tuned for part two and three of our Personas versus Mindsets series…