Ban User Personas in Development & Meet Real People

The usage of user personas as they are built today has to stop.  If you aren’t familiar with the concept that was developed in the mid-90’s….

Personas are fictional characters created to represent the different user types within a targeted demographic, attitude and/or behaviour set that might use a site, brand or product in a similar way. Personas are a tool or method of market segmentation.”

Meet Mort.  He’s 50 years old and he is a rocket scientist.  He’s been married twice with 4 children.  One of the things he does as part of his job is develop applications that connect to embedded devices used to test missile guidance system.  He doesn’t have the time to learn the ins and outs of programming languages so he relies heavily on visual tools and code completion services in the editor to help him write.

It’s too bad I don’t read fiction or I’d probably be better at writing it. Mort doesn’t exist, but to a couple thousand people building software at Microsoft he did.  He was a compelling character that helped drive the features and focus of several teams.  The genius was in the illusion of agreement about Morts character traits. This was a guy everyone wanted to get behind and help succeed at his job.  User personas, as a tool, are used to drive thousands of projects every year in the software industry, but it’s time for a change.

We are now in an era where customer connection is so painfully simple Mort can be replaced with real users.  User personas are not people and you are building something for real people.  Here are some of the issues with the use of this abstraction technique.

  1. You can’t ever ask Mort any questions. Once the persona has been made you can only consult the character sheet… Which only has information you have already collected about this perception of your customers.
  2. Personas are generally built with very little validation. It’s a tool that requires significant resources and dedication to use properly.  It’s rare that someone goes back to customers after interviews were conducted (that assumes there were interviews) to state, reflectively,  “this is who we are building our products for… Does this character speak for you?  My bet is that most people would say no and probably laugh at what they saw written on the character sheet.
  3. Personas allow you to be one step removed from anything real about the product or service you are offering. You get to have lots of meetings, visits, etc designed to facilitate building a persona instead of using those resources to offer a updated product or service based on what you heard… Why do you need the level of separation? Why not speak directly to people about the problems they want you to solve.  This practice is like playing the telephone game with the feedback that could be used to make your offering better. If you have people working for you that aren’t smart enough to draw the right conclusions from real information…. Why do they work at your company?
  4. Timelines. If you have to ship a product in less than a year… you don’t have time to do this properly.  By the time you’ve created agreement about the character traits they are probably outdated.
  5. The Fiction. Everyone loves to participate in creating neat fiction.  It’s fun and it makes it easy to create the illusion of agreement.  By the time the persona gets to an engineer, in an effort to make sure facts don’t get in the way of a good story details may have been omitted and some disparate customers may have been lumped together… Meaning the Frankenstein you created probably doesn’t exist. The people good at solving problems are now doing so with static variables that were set incorrectly.

So now what???

So what’s to be done instead? How should customer traits be aggregated into something that can do some good?

  1. Get real. If you must use personas do yourself a favor and find 5 real people that map directly to a persona.  Make the story about these five people and the challenges they face. Use only real quotes from these customers to rebuild the persona so it’s has a clear foundation in reality. Videos or audio are even more powerful.  Create a library of real data that everyone can read and a way to contact the real people behind the information.
  2. Trust Osmosis. Have a question, transcription, or some feedback delivered to your team every single day. This is only for reading unless there is something that can be done in 15 minutes to reply to the customer.  No big changes need to happen as a result of this feedback.  The big changes will happen over time thanks to the osmosis.   Everyone at your company should be spending 15-30 minutes today at least reading something from a real customer that is using your service.  This creates a personal connection that just can’t be delivered from a fictional character.  People want to know they are building something for other real people and they need to hear, from those people, the kind of positive and negative impact their work is having. Over time the realities will sink in and if larger changes are needed they will feel natural and no one will question these changes since they’ve been reading why they need to be made everyday.
  3. Leverage customer support. These people spend most of their days working with real customers that like your product enough that they didn’t give up at the first sign of problems… They let you know about the issues!!!  Of course you should make sure you solve their problem first, but then you should encourage a real conversation be had.  Rotate a set of 10 questions that you can ask people that contact support about how the software is working well for them.  Record the answers and share it with everyone.  I’m not talking about some canned survey, but open ended questions that would lead to a real 5-10 minute dialog.  This information will add up and you might find that, once you have the customer thinking about the positives they will come back to buy more of what you are selling later on.. If not on the same call.
  4. Make sure customer support is everyones job. Everyone can answer one question a week from a customer.  They don’t have to do it directly, but if you have people employed that can’t answer one customer question a week on their own… Why do they work for you?  When they do it, they get to ask their question and ideally engage in a real conversation with the customer.
  5. Use real data whenever possible. Does the data validate what the customers are telling you? Eye witnesses are the least reliable source of information on a crime seen… If you have real data on the behavior it needs to be put right next to the eye witness report.   If you don’t have numerical data to validate an observation it must be treated as an isolated observation until proven otherwise.

There you have it.  Leave the fictional reading for your vacations and get real with your teams.  If you like writing these stories… Take a class at your local community college, but don’t force fiction on people.  Take it from someone that’s been reformed.  There is no such thing as the ideal customer.  I used to be part of these definitions and seen them used well… But never as well as non-fiction.  Its so easy to engage in real conversations with people today it’s a sin to abstract that information behind fictional characters.

3 Responses to “Ban User Personas in Development & Meet Real People”

  1. […] This post was mentioned on Twitter by Josh (Telligent), mika loews. mika loews said: Evolvingwe » Ban User Personas in Development & Meet Real People […]

  2. Terri Morton says:

    Great post! It’s interesting to me to see what I consider to be a bit of a turnabout from you. I love the “find 5 real people that map directly to a persona” concept. RIP Mort.

  3. J.P. says:

    “Il est Mort”?

    Very nice actually.

    Seriously though no matter whether using a persona or not 3 and 5 are imperatives. Otherwise, in addition to fiction, then features are just based on personal preferences and at that point, unless product engineers also provide all revenue as well, there are no more target customers. Without knowing real customer pains and real customer usage data, then guessing at where to go next seems pretty silly.

    I think 1 can come from 3 as well and 2 may not completely scale to all levels, but at least withing engineering teams this makes sense.

Leave a Reply