Bruce McCarthy is Founder and Chief Product Person at UpUp Labs, where he and his team are at work on Reqqs - the smart roadmap tool for product people.

« Remember The Milk...But Forget the Work | Main | LookOut Search Plug-in for Outlook »

Personas Are Not Fictional Either

Last week I attended a webinar on developing personas put together by User Interface Engineering. Jared Spool was a bit distractible but explained things in a very approachable way. He described IUE's research methodology for creating personas, which involves 6-12 site visits, extensive note taking, analysis, persona development and incorporation of the personas into the development process.

Here are a couple of take-aways I thought you might find interesting.

Personas Are Not Fiction

A while back I wrote a piece about personas where I talked it about why it's a bad idea to base your personas on a single real individual. Using a real person as a substitute persona might seem like a good idea since you know that everything about that user is for real. The problem, though, is that one individual comes with quirks that may not be representative of the market as a whole. If you interview enough people, you can eliminate their biographical peculiarities by focusing your personas on the characteristics common to the group.

Jared also cautioned against adding a lot of biographical detail to personas, but he came at it from the opposite direction. He warned us to watch out for the temptation to make up background info on your personas. He did recommend giving your persona a name (though not the name of a real research subject for the reasons above) and even finding a reasoanble-seeming photo of that person from stock photography. Both of these are to make the persona more real, easier to remember, and easier to talk about. He said, though, that the color of their eyes, the kind of snacks they like or other details that don't relate to the product you are trying to design are just distractions. He argued that you should eliminate any detail from the persona that you can't connect with a design decision you need to make.

I asked about his inclusion of age as a detail in an example persona they were showing for a medical application and he reasonably replied that age, if representative of the real people you interviewed, could tell you something about the level of computer-sophistication of the user. He emphasized the word "representative," saying that otherwise you were "just making stuff up," and that didn't make for useful design tools.

See a great response Jared posted on his blog to a rant by Jason Fried of 37Signals about personas being "artificial, abstract, and fictitious." Jason sure missed the mark here and I was glad to see so many responders taking him to task.

Clusters Lead to Personas

Another thing I took away from the seminar was a method of extracting data from interviews and turning it into personas. I usually take a lot of notes during customer interviews. When I am finished with them all, I go through and look for key data points like reports people want to see, goals they have, frustrations they have, tools they use, etc. Then I count up how many people use each tool, for example, to get a picture of what people as a whole are using. This is not a scientific, quantitative approach, but it's often directionally helpful.

The folks at UIE have developed a method of clustering these data points about their subjects (they call them "informants" but that's a little too CIA for me) that helps them develop multiple personas. They compare and contrast the individuals they interviewed and plot each on a series of sliders. They pick a subject they interviewed them on, say, computer-savviness, and they plot all the users relative to each other. They do this for all aspects they can then look for patterns in the charts where individuals seem to be close together on several sliders. Looking at what these clusters of neighbors have in common is how you then generate the descriptions of personas.

One of the key things this method does is to weed out irrelevant detail. It might be that all of the neighbors in a particular cluster are young while other clusters seem to skew older, so that's a good bet for a detail to be included in the persona. It might also be that the majority of your subjects overall drive Fords but if you find there is no consistency as to automotive brand choice within clusters or little contrast across clusters, then auto brand preference is probably not relevant to the personas you are going to write up.

I find I like the rigor this clustering concept seems to bring to the qualitative process of developing personas and I plan to try it out on my next project. Hope it's useful for others as well. 


Reader Comments (3)

Thanks for the great writeup.

One quick note: I can't take credit for the clustering process. It came from many sources, but the bulk of our technique came from Kim Goodwin at Cooper, as described in this article.

-- Jared

November 21, 2007 | Unregistered CommenterJared M. Spool

The key problem I have is *how* to build those "sliders", as you call them---also known as "behavioral variables".

I mean, which pair of key facts should you use in each "slider"? In all cooper's books and web articles they always use the same example (which is irritating and frustrating):

They make a "slider" with "price-oriented" people on one side and "service-oriented" people on the other. How do you come up with those two options? How do you know which pair should you be comparing against?

Was any of this mentioned in the webinar? Do you have any idea of what I'm talking about and how to solve my problem? :) It would be greatly appreciated, because this is driving me crazy.


January 18, 2008 | Unregistered CommenterRafa

I do understand your question. It's a good one but you probably won't like my answer. As Jared Spool is fond of saying, "it depends."

Obviously, you are attmpting to plot opposites (computer-savvy vs. not, old vs. young, rich vs. poor) but which do you choose? It really depends on the decisions you are trying to make in developing your product.

To use your example, it probably arose because the product manager was trying to decide whether to provide a service as part of the offering. Realizing it would require a charging a higher price for the offering, s/he asked a lot of questions about price vs. value trade-offs and then tried to plot each customer on a contuum from, essentially "won't pay for more service" to "will pay for more service."

If all of the customers fall on one side of that equation, the answer is simple. If they are split, then you probably need to make the service optional and you can use the relationships between the sliders to help you decide what other things to bundle that service with based on what the same people value.

Hope that helps!

January 18, 2008 | Registered CommenterBruce McCarthy

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>