.jpeg)
I've been both an advocate and adversary of user personas; the side I’m on largely coming down to how they are being written more than whether they remain as a sheet of unvalidated assumptions.
This is because, more often than not, I've seen (and have admittedly created) personas that are mostly just a fluffy collection of context-less behaviours, feelings, pains, and values. And, as a result, the product and design teams really aren't left any wiser in terms of what may or may not work for that type of person.
An example of that all-too-common type of 'Persona' would likely have content like: "Meet Sam the Software Developer, a technologically-gifted man in his 30s that values his young family but is also quite time-poor due to his work and side projects. He's used to shopping online and uses his mobile phone for most purchases.” Yadda yadda yadda.… more average demographic data and generalised segment ‘values’ that makes it sound like Sam does the same thing every time, everywhere.
Okay, great, you’ve gotten that ‘deliverable’ done (don’t get me started on personas as deliverables today)... but if the product and design team is redesigning the online shopping experience for a florist, how well will knowing those ‘traits’ about "Sam” give them any actual insight or direction?
(This topic and example was directly influenced from Larry Marine in this Delta CX Episode 87: Improving Your Observational Research - a great listen; these are my inspired thoughts).
In come Task-based Personas, created just-in-time around specific [and hopefully validated] scenarios and needs.
The team can still get to “know” Sam, but most importantly, know that by being so dedicated to his projects and working late every day, Sam's partner has started to feel alone at home (or maybe they got in a heated argument last night, pick Sam’s RPG adventure haha). Feeling terrible now after consciously realising that he has been prioritising work over family, he wants to show that he's sorry and the idea of buying her flowers came to mind.
However, Sam is absolutely clueless about which flowers have which meanings, what types have what smells, or which ones his wife might even appreciate. And on top of that, despite how deep of a ‘hole’ he feels like he's dug recently in their relationship, when it comes to spending money on gifts, he’s still quite stingy and will be looking for a deal once he realises how much flowers tend to cost.
That gets straight to the point, doesn’t it? It’s heavy hitting and unambiguous - Sam’s core values and present emotional situation are clearly on display here.
So, if the florist’s web team were interested in designing an enticing experience for customers like Sam, then this type of task-based persona should really start to spark a whole host of new ideas. Would a front-page hero block advertising their 'apology' bouquets that are sortable by price be a good proposition to test? Quite possibly - it’s just one of many possible solutions - but the point is that the team has a key place to start.
Similarly, perhaps the team has uncovered a common, secondary task-based persona called "Philippa" based on their customer behaviour and testimonial data - specifically, women who love having flowers in their homes and who have been known to occassionally send a really bright and fragrant bouquet to their mothers just as a cheerful, thoughtful “thinking of you” gift.
In that case, the team would know that they’re dealing with customers who are far more knowledgeable about all-things flowers and who come with a target idea already in mind. So, once again thanks to the deeper understanding of these customers' key tasks, values, and pre-existing knowledge, the team can discuss, design, and seek to test very specific product and design solutions.
Best yet, aligning these personas to a specific task breaks the next-worst habit of teams taking one persona and trying to re-use it for multiple products, projects, and problems. That misleadingly conservative approach usually has someone express some sentiment around getting the most “bang for their buck” out of all the time and money they spent developing those personas, so why can’t they reuse Sam and Philippa for people shopping for potting soil or gift cards?
Let’s just hope that after using his task-based persona for ideation that the team doesn’t earnestly think that Sam is going to want to come home with a bag of potting soil or a gift card as his apologic gesture, let’s really hope not…
So write ‘em up, have a think, and throw ‘em away. Let scenario and task-based personas help your team get talking and then let those just-in-time artefacts go; they aren’t your sellable end-product.