Personas: A closer look at two methods

I recently read an article from UX Mag (2011) about personas*. The article described a very traditional approach to creating personas — actually what I learned in grad school — which is different from my experiences at work with “proto-personas”. I wasn’t familiar with the term proto-personas until after I’d participated in creating them at work. To learn about this term, I read a different UX Mag (2012) article about proto-personas and I noted the discrepancies between the two articles immediately.

I thought it would be interesting to compare the two different persona articles, and share my experiences with the approaches described in each one.


Method One: Personas, The Traditional Approach

Personas: The Foundation of a Great User Experience, UX Mag, 2011.
As the author states, this is a primer on personas and how businesses can use them for their organization.

The main activities of this method involve interviewing approximately 30 people. The team then analyzes their responses to find common behaviors and thought patterns, as well as the elimination of extremes. The team then uses the findings to conduct an additional round of research with 5-7 individuals in order to validate and fill in information that was previous missed.

Conducting 30 interviews takes a lot of resources and time, and the article states that the investment in a persona project like this can cost $80,000. In these days of Agile and Lean UX, this estimate strikes me as an expense in time and money that most businesses and clients simply will not be willing to spend. However, the results will be extremely valid and based on actual user data, which is a major aspect of “user” experience.

Personal Experience:

My experience with this type of persona development goes all the way back to 2004, in my grad school days at Michigan. Our project was to complete a thorough usability evaluation of Yahoo! Avatars, which allowed Yahoo! users to create customized avatars for their online chats. We’d previously analyzed the interface, so this wasn’t the first exercise in our evaluation project. We split the work, and spent about 1-2 weeks collecting interviews and analyzing our data. We did find patterns of behavior among our interviewees that we then turned into personas for our project. Although we didn’t spend as much time on the activity as described in UX Mag, I felt very confident that our personas were accurate.

 


Method Two: Proto-Personas: Getting a seat at the table

Using Personas for Executive Alignment, UX Mag, 2012*.

This goal of this article is to sell the value of personas to executives, or clients, as a way to increase the value and visibility of user experience within an organization, and to describe how to do it.

The main activities of this method involve a 2-day workshop session, with the executives, in order to get them involved and invested in the personas. It goes like this:

  • Day 1: It starts with a proposal, where the goals of the persona workshop are defined. Each persona is defined using 4 quadrants for: high-level basic demographics and a sketch, behaviors and beliefs, demographics, and needs and goals. Each person does this, and as a group they decide on which assumptions are more or less accurate. Following this, each persona is placed on each of 5 spectrums, to differentiate between them each one. The results are digitized.
  • Day 2: The next stage is review and validation of the previous day’s activities, and to use the personas right away in a design workshop.

The investment is only 2 days time, so it’s very accessible to many teams, if you can get executives to participate. However, the important thing to keep in mind here is that these personas are based on assumptions and beliefs, not verified user data. Eventually, these personas will need to be validated with other research methods.

Personal Experience #1:

My experience with this type of persona involved preparing personas for a recreation-vehicle client. Our client was based in Canada, and visiting them for a group session wasn’t possible. The decision was to create the personas, then send them the results for their validation with their marketing team. Our team got together and created the 4 quadrants for each persona. We spent about 15-20 minutes on each person, coming up with ideas to fill in each section. After this, I digitized each persona using Keynote, using a very graphic style. (I don’t recommend Keynote for design purposes.)

In all honesty, I felt like we were just guessing when it came to filling in the quadrants and I felt lost throughout the whole process. Based on the client/product we were designing for, I attributed my confusion to a difference of life experiences or simply that the other people on the team had more information than I did. Perhaps working with executives, who spend time regularly studying their customers, I would have had a different experience.

Personal Experience #2:

My other experience with proto-personas came when supporting the Shared Shelf project for Artstor. In this case, we also relied on non-user data to create the personas. I researched job descriptions for each user type, and created roles for each persona that were then validated by subject-matter experts on our team. The personas were then digitized by our Creative Director using a very sophisticated graphic style and presented to the clients for further validation.

These personas were used in user flows, and they seemed to work very well for this purpose. I do think that maybe the extended team wasn’t as invested in them as much as they might have been if the workshop method had been used. Granted this was in 2009, before either of these articles had been written.

 


Summary

My opinion is that the traditional approach is best, although I feel that the group participation aspect of the proto-persona workshop is very helpful in getting buy-in from the extended executive or client team. I am dubious that the particular approach my team used for the recreational vehicle client was at all accurate; it simply felt like make-believe, so I would not recommend that. The approach using the job descriptions was not entirely accurate either, but I felt that it was at least based on assumptions that other people familiar with the user roles had written. Whichever method you choose, it’s important to validate your creations with real users and to use your personas in your work.

I hope that these links and my stories are of use to you, in your team and in your practice.

Links:

Note that the second article was written by Jeff Gothelf, who wrote the book Lean UX (which advocates for proto-personas).

*If you’re not aware, personas are archetypes of users and are used to represent a user type as opposed to a specific person.

Leave a Reply

Your email address will not be published. Required fields are marked *