This is an interesting write up by Kai Wong. He raises the questions about why personas still fail? and What does a successful persona look like?
Kai talks about how important it is for the design teams to not just create personas in silo for their reference. But also to present the value that it brings for the business stakeholders.
He raises an important point, in his own words:"If Personas don’t influence the rest of your stakeholder team, then it’ll be effective for however long you’re on the project and part of those meetings.
And then it might be forgotten afterward."
We should know everything about personas at this point: they’re a staple in every designer’s toolkit, and they’re taught it courses and boot camps alike.
So why do personas still fail? Because we’re still not designing with our stakeholders in mind.
And to explain this, let me ask one specific question: What does a successful persona do?
Success and failure with personas
The purpose of personas for designers is clear: it’s a tool designed to understand who the user is, based on research, that is supposed to guide them in making design decisions in the future.
And you might be tempted to stop there.
But have you asked what the purpose of personas is for stakeholders?
After all, you’re not making design decisions in a vacuum. Stakeholders are paying for user research and development of these personas: are you simply just showcasing them in a single presentation and sticking them back into your workspace?
This is, in large part, why personas fail in organizations: more often than not, personas are created in a silo, for designers only, while the organization sometimes grumbles about not really having a clear, simple, and concise picture of their customers.
So let me ask again: What does a successful persona look like?
I like what the Nielsen Norman Group says about this: Personas make users memorable for your product team.
A successful persona can bring a snapshot of your user to your customers. More importantly, if they’re memorable, team members may start to refer to them in shorthand when making decisions, meaning that you’re aligning their thinking to be centered around the user.
Kind of like User-Centered Design.
So what’s the first step in actually making personas that users will remember?
By making it realistic.
The power of realism in personas
It sounds strange, to think about realism. But realism is something that people often forget about when thinking about creating design artifacts like personas.
I too have struggled with authenticity in a lot of my work. One of the worst design experiences was when someone laughed off the concept of personas.
As a result, I have tried to make sure that everything has an authentic tone to it.
And that’s one of the problems with personas. These things can easily laugh off if not careful: we’re essentially creating a fictitious user (albeit from user research) and then coming up with fictitious stories that are somehow influenced by your product.
And that doesn’t encompass exactly why someone would use your product. Just because someone is a 46-year old who may want to buy shoes doesn’t necessarily mean they would even know how to figure out how to get to your site.
This is why the Jobs to be done format for personas can be useful.
The JTBD format asks the question: Why would someone ‘hire’ a product or service?
Rather than abstract motivations (such as being motivated by hearing about this new site), putting things into this format allows a specific feature or functionality to be called out as a primary motivator. For example:
“Sally, a 46-year-old mother to a child with health complications, wants to ‘hire’ the Apple Watch service because she can track heartbeats.”
Highlighting a user by creating realistic scenarios helps to bring this in the right direction.
But that’s not all.
The importance of common ground and simple language
A persona, like many other design artifacts, should be thought of as an anchor point. It is a shared document created by talking with stakeholders, users, and then brainstorming to create a realistic and relevant user.
So why would you assume that other people within your organization wouldn’t find it useful?
Creating personas and then never using them is one of the reasons why personas fail. Worse yet, it makes it harder to get buy-in for future iterations of personas, because they invested time and money in and got nothing out of it.
So you want to make personas as accessible as possible to make sure that they’re used. I want to put, as a reminder, that UX Design is a new field, with the term being coined in the 1990s.
Some people have never heard of personas, UX Design, or anything that you do.
The goal should be that even if they don’t know anything about this technique if they were to pick one of these up, they could tell that it is a representation of a user.
In short, this means that each category and wording should be able to be understood by someone who may only have a passing knowledge of the subject. Even if the persona is a targeted-scope UX persona, where it may be someone with specific expertise or knowledge, other members of the organization should be able to recognize what it is.
And more importantly, what they should do with that.
The importance of key takeaways
Part of understanding how your organization would view this is showing easily understood key takeaways that people can use to take away from this.
As a Designer, you may be in the thick of things: you’re building personas based on user research, which you’ll take to inform other design artifacts (like journey maps) or keep in mind as you’re designing prototypes.
But if someone’s coming into looking at your personas as a way of reviewing what’s been done, are they going to know what to do with this thing?
Not everybody knows why personas are useful. So if they see something like that, are they just going to nod their head, smile, and then promptly forget about it after a presentation?
We as designers can do our part to educate stakeholders about personas. We can teach them about the importance of personas and UX Design.
But I’ll talk about a scenario that you might encounter. Imagine you’ve given a presentation about your personas a couple of weeks ago, but in a meeting today, one of your stakeholders brings up a suggestion that runs against the persona that you researched.
You just so happen to have the persona on you. What exactly would you want to point out in the meeting when you only have a few minutes?
Is it immediately obvious to talk about? Or would you need to explain that it’s something that’s not on the persona, but when you came across this in research, you saw it?
The second is an okay example if you’re part of that team. But what if you’re not at that meeting?
If Personas don’t influence the rest of your stakeholder team, then it’ll be effective for however long you’re on the project and part of those meetings.
And then it might be forgotten afterward.
It’s not all doom and gloom: personas, if properly implemented, can act as a proxy user in almost any meeting that you attend. While it’s no substitute for talking with actual users, having them be both memorable and present in these meetings is something that can change how your organization thinks about users.
You just have to remember to design for them.
Questions to ask when designing personas
So here are some questions you might want to ask when thinking about your stakeholders:
Is the persona easily summarized?
If you took a random employee who works in the Collections department, for example, and showed them a persona of someone who would interact with Collections, are they going to understand what this is?
Some ways to make it easier to summarize include easy to digest primary motivations, problems phrased in ways the average user will understand, etc.
Does the persona provide actionable insights?
When you’re talking challenges, is the scope of the problem large or small?
Something like “Is frustrated with having to re-type information.” Is easier for people to understand and take steps to address versus “Is frustrated with the process being tedious.”
How does this align with stakeholder’s mental models?
If someone’s had 20 years of experience working on a project, you don’t want to say that this persona knows users better than your stakeholder. So what are the similarities and differences with how your stakeholders think?
Being able to say something like “While we are mostly aligned, there is this one aspect that you might not be aware of…” is likely to help.
I write about UX, Healthcare, and Productivity regularly.
Reference:
Kai Wong also has a course which help you learn how to communicate as a UX Designer, check out his online course here.
For the published article on medium please click on below link: