Clap If You Believe (In Personas) – Part 1

An engineer once described a persona exercise as “theater camp.” I thought about that for a while and realized what she was getting at. Here I was coming from the UX world, running the team through a song and dance exercise with imaginary people, stickies, and line drawings. The “creative” (me) felt comfortable — I was in my element — but to the attendees it was like a nightmarish new-age UX drum circle.

It was like a wrestler doing their first yoga class. Or me doing pair programming or trying TDD. I told the one about role playing games being the inspiration for personas. Crickets. My jokes fell flat. One solution—retrench and consider personas as the UX rallying call. (People are going to play along whether they like to or not, embrace my powerful UX Empathy!) But I think that is shortsighted. I’ve experimented and have found some things that work.

Yes. They’re Fake

Personas have a shaky reputation among software engineers. And that’s being generous. I’ve been in numerous situations where teams openly (and forcefully) expressed their distrust, dislike and aversion to personas. Mini revolts ensued and hand drawn posters faded and magically disappeared. One engineer described personas as the “Joe The Plumber”-ification of software development. Ouch.

In the words of engineers they seem “fake”, “contrived”, “artificial”, and “forced”. It would be easy to write this off as a lack of empathy or imagination (which ironically is reverse lack of empathy), but in my experience the opposite is true. Teams genuinely want to connect with users.

The reality is that personas, at least initially, are all of those things — fake, forced, and contrived — while at the same time personas are extremely valuable.

Pick a character from a favorite book. You’re pulled in by the story. At page one-hundred of John Steinbeck’s Of Mice and Men we know Lennie and George well enough to predict impending doom when they meet Curly (and Curly’s Wife). The characters are “real” because we suspend reality long enough to embrace the fiction.

Ethnographers and UX researchers do the same: suspending surface stereotypes long enough to embrace a more complex reality after spending weeks/months in the field.

Both take a leap of faith—to start with something wishy-washy and fake, stay curious, and keep digging for something more poignant and actionable. We create a generalization as a starting point for learning. Personas are helpful. Use them correctly and you will develop better products. Force them on teams— “inflict” them on teams, to quote an engineer—and you’ll erode trust, detach the team from the user/customer, and harm the end-product.

Whip-Cracking Personas

The worst abuse of personas is when they’re used to basically tell people what to build and who to build it for. They embody the why, who, what, and how without any room for exploration and disagreement. Any person in their right mind will start ignoring these and thumb their nose. In a retrospective an engineer once exclaimed:

You want me to spend the next three months of my life working on something for an imaginary person you dreamed up for the kick-off deck?

Yes, I’m Guessing

A great start is to eat the humble pie and openly acknowledge that you’re guessing. This seems trivial, but it might not be immediately clear to the team that you are consciously and intentionally “making believe”. These “proto-persona” (a first pass persona not based on validated assumptions) represents your best guess at the moment. The challenge of product development is to iteratively validate these “who” assumptions. Who is this fictional character? What job do they do? When we’re one-hundred pages into this book, what will we know?

How do you structure and visualize this approach? Instead of a static (and quickly stale) persona, we’d use a Kanban board (or “canvas”) to prioritize assumptions, and then plan and execute experiments.

The challenge here is that openly acknowledging how little we know is not exactly the stuff of CTO and VP of Product dreams. It makes people uneasy. Validated experiments don’t result in deployed 1s and 0s. Teams are frequently measured in terms of output, not outcomes. But if you foster a culture that is failure-safe and focused on learning you’ll be surprised by the engagement this inspires on the team.

If you’re going to make the persona (and your assumptions) visual, commit to keep iterating on the content as the team learns. A stale persona is worse than no persona at all.

“Real” People

Another approach — and one I’ve found very effective regardless of organization culture — is to focus on “real” people instead of generalizations. This is the persona gateway drug for the uninitiated. Knowing that this human actually exists in flesh and blood does wonders.

At first, I was skeptical and braced for the valid “low N” argument (focusing on one person is the queen of small samples). In a fit of “ok, I’ll try personas one last time” I took pictures, video, and audio. I had the team design their own persona template based on a collection of real humans. Together we referred to the users by their actual names.

These “personas” —while not strict personas—came alive. Because they were actually alive. The team could jump on the phone and chat with them. What was impressive in this case was that the team had a much easier time moving from the specific to the general. They noticed commonalities. We developed generalized personas by going backwards—which essentially mimics how skilled designers and marketers create personas in the first place. It was a good example of experiencing the thinking process instead of mandating it. (Starting with Fake Fake People rarely gets you to “Real” Fake People).

More to come on personas and how to approach them in this Thursday’s “Clap if You Believe In Personas: Part 2” post. You can read the complete personas post from Senior Product Manager, John Cutler, here. Be sure to subscribe to Pendo’s blog for more posts from our product management and customer success teams each week.