This is a continuation of our previous personas post from Senior Product Manager, John Cutler.
Salience: Try new methods to collect persona details
People can be extremely lazy with the types of media they use for personas. And designers are often the main culprit. They’ll create complex and beautiful persona templates and miss out on opportunities to use video, audio, and work product samples (e.g. spreadsheets, forms, plans, etc.). The persona templates are so rigid that any new learnings are impossible to incorporate. In short, they’re made for Show, and not Tell. Cute for portfolios, but not so helpful for teams.
Let’s say you’ve interviewed ten people and you start to find some commonality around the technology usage dimension. Consider editing down clips of video (or audio) for that dimension and splicing it back to back. This will drive home the point with more salience and impact. Most importantly you’re letting the team explore the connections instead of force-feeding your biased summary of findings. Work backwards from the specific to the general, not the other way around.
The granddaddy of persona fast tracks is the “real world” customer visit. Rent a van and go. I’m amazed by how few product managers, let alone engineers, actually engage with their customers and users in their offices. Reality check—your precious UX breaks down with eleven open browser tabs, interruptions every three minutes, and a barking boss down the hall. No slick persona can replace this real-world experience … especially when it’s delivered second hand through a UX researcher or product manager proxy. Taking a full day off and away from the screen might seem like a productivity killer, but so is building things people will never use.
In a pinch, video can work if your org is pushing back on out-of-office visits, or if visiting customers on-site is impractical. At a former gig I filmed “confessional” style videos with twenty-odd customers/users. I set the context and lowered the customer’s guard. No topics were off limits. The end result was “loved” by even the staunchest persona haters. It felt real. The same held true for monthly customer research panels where we invited customers to speak to a room of 15–30 engineers over lunch. Even the staunchest persona-loathers enjoyed these sessions (and the free lunch didn’t hurt).
Salience II: The importance of stories
What excites people more: 1) knowing how old a person is and that they like puppies or 2) knowing that a person saved a stray puppy from freezing water on the eve of their 30th birthday during a freak ice storm in Wisconsin? Personal stories are more compelling than fast facts or bullet points.
Check out the periodic table of storytelling and get lost for an afternoon.
The summary-style nature of personas is their Achilles’ heel. I remember interviewing a person who was caught in a terribly difficult financial situation. He was terrified that he would let his elderly mother down by mismanaging the property she had entrusted him to rent. Her care at the assisted living facility depended on it. Now that’s real. No bullet point can capture that. Playing the audio to the team captured it perfectly without any platitudes about empathy.
This is why personas should be used in conjunction with customer journey maps and other time-based visualizations and artifacts. Don’t feel limited by the format or template of the personas. Consider storyboards, picture montages, video montages, and more traditional journey maps.
Some of the caveats above still remain true. A “proto” customer journey map is still a hypothesis. Making it more visual doesn’t solve that problem. But by “working backwards” from qualitative research you can make these exercises pack a bigger punch.
Salience III: Try “Jobs To Be Done”
Jobs-to-be-done is an interesting counterpoint to traditional personas and something I’ve seen resonate with product development teams. I’m not sure I’m a fan of doing away completely with personas, but I do think jobs-to-be-done makes a great case for focusing less on the classic product marketing wheelhouse of demographics and stateless, causality-lacking generalizations.
With B2B you frequently encounter situations where you’ll have customers who wear different hats depending on the size of the company. Users are grouped by needs and goals (both emotional and job-related). Imagine two CEOs, both with similar demographics. The president of a small company might wear “all of the hats” while the CEO of a large company focuses on top-level decisions. The SMB president embodies many jobs-to-be-done, least of which is trying to manage the wrenching stress of overseeing a small business.
There is a subtle difference between
“This person is stressed. This person is overworked.”
and
“This person is hiring our product to reduce stress in their day and to work more efficiently.”
A big word of caution: Don’t put too much emphasis on official roles prescribed in your product. What is an Administrator exactly? Are they all the same? Do all Read Only visitors have the same needs? Don’t create personas directly from your system-roles.
Salience IV: Relationships Matter—No Persona Is An Island
A major failing of traditional personas is that they fail to describe relationships. Relationships drive collaboration and interactions. Relationships create product challenges that extend beyond the singular wants, needs, and egos of individual people. Understanding relationships can engage teams which in turn drives empathy and novel solutions.
Let’s say you have a golfer and a caddie. What are the inputs and outputs of that relationship? The golfer is relying on the caddie for local knowledge and emotional support when she shanks the ball into another fairway. The caddie is relying on the golfer for money, for conversation (perhaps), and for regular work. Both have a relationship with the Pro and other Golfers.
The relationship view is a much-needed layer of understanding. The real opportunities for products often exist along the edges … not at the nodes. Work passes between people, not inside the confines of single personas. A successful product addresses the needs of all parties. These diagrams don’t fit into the neat and tidy persona templates, but they express a more realistic set of assumptions.
The Why
Observing humans is one of the great catalysts for invention and innovation. It’s how you develop products that magically read the customer’s mind even if they’ve asked for something entirely different. You notice the subtleties. Your design decision batting average improves.
But as they stand, personas have a bad rap. Framing personas merely on their capacity to drive empathy is too short sighted. And frankly, it also feels elitist. It casts engineers as lacking empathy for users when in fact they rightfully lack an appetite for shoddy assumptions.
There’s a couple reasons why “experienced” cross-functional teams perform better. The first is that they know when to trust and challenge their intuition. The second is that they know how to ask better questions and that staying curious is the key to the game. Third is that they combine techniques and have mastered the core skills (“just code and deliver” below). Personas, and their inherent ambiguity, definitely make things more complicated, at first …
When working with an inexperienced team, this can be a challenge for the UXer. You know that the persona process can yield better, leaner, more simple, and more effective product … but honestly, it all feels a little hokey. Hopefully, the advice above helps, and I’d love to connect to learn what has worked for you!
Don’t do personas for the heck of it. Build better products together.
Subscribe to the Pendo blog for more weekly tips and insights from our product management team. Read John’s original post here.
