Not really my field, but the page itself is a nice example of how to do a "get our newsletter", not with a dirty great popup that you have to dismiss, but with a discreet little thing in the bottom-right corner.
Personas are problematic when they assume goals and values of users. I've seen many product teams create personas or jobs to be done that literally come from their own idea of what "someone like that" or "someone in this role" would need. Conversely, when we start with the idea that we don't know, define a customer and then ask them unbiased and non-leading questions about what they have done (NOT what they 'want'), it doesn't matter as much whether the framework is personas, JTBD, or any other approach.
Agree. Good tools like personas, JTBD, or whatever are a result of well-done research, not assumptions. As soon as assumptions enter the mix, the tool (and therefore decision-making) is biased and will give you the wrong information.
Yeah, there's the same kind of problem with pretty much all "mental frameworks for improving the quality of X".
If you follow the steps mindlessly, you get nothing. Potentially less than nothing, since now you appear to have more authority than if you had not.
If you use it to think better, i.e. to expose your blind-spots or do something more carefully than normal, the steps barely matter - the goal was achieved, you're thinking better.
Every system can be "gamed" / undercut if you're determined or lazy enough. The goal of these systems is to break people out of that habit (whether they're aware of it or not), they can't guarantee it's done.
The article touches a bit on this in terms of "proto-personas" and suggests an alternative method (assumption maps). To me, there's a point that you can build products from assumptions. You'd be trading risk (less validation) for speed and perhaps focus, which isn't inherently wrong. But most importantly you shouldn't pretend it's unbiased, user-driven, or that there aren't blindspots. And you shouldn't use personas as the tool of choice in that case. The distinction is rarely made though and problematic.
Article is spot-on about personas being misused. The author provides some good guidelines for getting them back on track, but I've had more luck simply abandoning the personas concept altogether.
Personas might be useful as a brainstorming session to identify pain points, product interaction context, and problems to be solved. However, once those key goals have been identified, why not simply abandon the persona concept for the rest of the process?
Focus on solving the problems you've identified, not appealing to 3-5 extremely specific imaginary personas.
I know what you're saying, and I think this is why lots of people are abandoning personas in favor of things like JTBD. But I think personas (or something similar) can be useful for those other parts of the process, especially if they're based in research and aren't "imaginary".
For example, thinking about how a particular user flow would work for a specific relevant persona/JTBD is useful for design decision making. It helps you see things from a user archetype's eye, rather than through your own designer eyes or through the eyes of "the user" which isn't specific or helpful.
This is all assuming, of course, that you're building personas correctly, which in my experience is rarely done.
I think the concept of a persona has morphed and been abused over time.
With my team we use them as a tool to organise a set of assumption's or hypotheses that we want to test. Then through further user research tools we look to validate these assumptions.
On the whole it's not perfect but it works well most of the time.
This is how I use them too. Personas are the idea or target, you validate the persona against the data collected related to segments/cohorts, etc. Drift of cohorts from personas shows a change in behavior that needs to be understood.
It’s a disappointing misunderstanding to see the blog post lead with design != marketing personas, and then try label psychographic and demographic usage against each, respectively.
Marketing is finding product market fit. Product is a sub-category of marketing. Design is a function that contributes to product.
11 comments
[ 3.4 ms ] story [ 36.4 ms ] threadIf you follow the steps mindlessly, you get nothing. Potentially less than nothing, since now you appear to have more authority than if you had not.
If you use it to think better, i.e. to expose your blind-spots or do something more carefully than normal, the steps barely matter - the goal was achieved, you're thinking better.
Every system can be "gamed" / undercut if you're determined or lazy enough. The goal of these systems is to break people out of that habit (whether they're aware of it or not), they can't guarantee it's done.
Personas might be useful as a brainstorming session to identify pain points, product interaction context, and problems to be solved. However, once those key goals have been identified, why not simply abandon the persona concept for the rest of the process?
Focus on solving the problems you've identified, not appealing to 3-5 extremely specific imaginary personas.
For example, thinking about how a particular user flow would work for a specific relevant persona/JTBD is useful for design decision making. It helps you see things from a user archetype's eye, rather than through your own designer eyes or through the eyes of "the user" which isn't specific or helpful.
This is all assuming, of course, that you're building personas correctly, which in my experience is rarely done.
With my team we use them as a tool to organise a set of assumption's or hypotheses that we want to test. Then through further user research tools we look to validate these assumptions.
On the whole it's not perfect but it works well most of the time.
Marketing is finding product market fit. Product is a sub-category of marketing. Design is a function that contributes to product.