As I mentioned in a previous post, I recently completed a Skillshare class on iOS design. The focus of the course is to take an existing app and update it. Part 1 of the 3-part course is all about UX design. The instructor takes students through planning, personas, user journeys, and wireframes. Here is the work I did for Part 1.
The app I selected was Axis 360. This is an app that allows people to checkout audiobooks and e-books using their library card. It’s an app that I’ve been using quite a bit and I wanted to focus on improving it if possible.
The first thing I did was take screenshots of the existing app.
The course then begins by creating a high level list of activities someone can complete on the app. I focused on listening to an audiobook. The instructor used sticky notes, so I did too.
From there, I created a high-level user journey. This includes a screen with a list of checked out books, a book detail screen, and a playback screen.
At this point in the course, the instructor introduced personas. In this case, these were proto-personas. I admit that I did not complete this part of the 3-part course.
My philosophy is that personas are only useful if they can be validated by objective data. This includes providing completed personas to a client, or by interviewing potential users. In my case, I had neither a client nor potential users. Unvalidated user needs, demographic data (age, marriage status, gender), and interests (stock-car racing) would be a work of fiction and thus useless in directing the experience. So, I skipped this step, although I came back to it during the visual design phase.
In the next post, I’ll talk about sketches and wireframes.
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.
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.
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
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.
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.