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.

2016 Web/Portfolio update

I’m writing this from the middle of a major update to my website and portfolio.

As I’m currently out of a job – yes, it’s true 🙁 – I’ve been a lot more money conscious. I’ve come to realize that many of these DIY, portfolio builder sites have been siphoning money out of my wallet for years. I was using the free version of Carbonmade, but over time my use expanded in order to accommodate a growing list of projects. Month after month, I’m just paying $7.99. Too much!

So, I decided to get away from that and migrate to a simple PDF. A few reasons for that:

  1. In researching “good” UX portfolios, I found this a post on Creative Bloq, with the top portfolio from a UX designer named Erica Firment. As it happens, we both went to the same grad school at the University of Michigan, School of Information. While her website is very impressive and tells a good story, her actual UX portfolio is a PDF.
  2. The second reason was I found this excellent portfolio guide, published by the University of Cincinnati’s, DAAP school (another personal connection). It’s a very excellent resource in putting together a very nice PDF portfolio.

(I also know that General Assembly published a guide on putting together a PDF portfolio, too.)

So, given this little research, I decided to cancel my online subscriptions and put together my own PDF – which, I’ll be honest, was faster and cheaper than fussing with an online interface. My main goal was to get started, and then upgrade overtime. For the first iteration, I used Omnigraffle. It’s not ideal for this task, but it’s very fast and it handles images really well. Just drag and drop, no “place” necessary. My main goal was to just finish so that I would not get charged for another month for any longer than necessary. At first I followed the Firment model; using icons and a few colors. But, it seemed really kitschy, so I got rid of that in favor clean fonts and layouts.

After finishing that, I decided to move to InDesign, which was the goal all along. InDesign allows me to use the same fonts and styles from my portfolio on my resume, which I’ve been making in InDesign all along. I went with an 11×17 landscape layout, because it will present well onscreen. And, if it’s printed, it will size proportionately and the font won’t look super tiny. It took me about a week to upgrade to InDesign, but now it’s all done. I’m happy.

Moving on now to updating my website…again! Websites are never done, right?

The Blog is Back!

After several years of nothing, my blog is finally working again (fingers-crossed)!!!

I truly am at a loss to explain what happened. It’s been so long, I can’t attribute it to anything specifically that I installed or failed to install, or migrate, or deleted… Who knows. I know this Twitter feed thing isn’t working right. I need to find out what else is broken. I doubt all the pictures show up correctly, but they appear on and off on the backend.

I’d recently decided to move my blog from WordPress to Jekyll, as I’m doing so much with learning to code these days. I thought it would be a nice experiment, and also I’d have more control over the output. It might be a good idea to continue with this anyway, since I am not sure how long this will last. However I’m currently having issues with Ruby and Jekyll, and not all of the plug-ins that are supposed to work seem like they are working.

On the other hand, this might be a good excuse to dive more deeply (or start, really) learning about WordPress customizations, theme development, and WordPress administration customization. More PHP and MySQL stuff, which is where I was headed anyway.

In any case, I feel excited…finally!!


For more information about migrating a WordPress blog to Jekyll, there are a few resources that might be helpful – although if there can be trouble, there probably will be!

Building up HTML Skill

Normally, I do not spend a lot of my time using HTML or CSS, but I got a little caught up in reading on UX blogs and discussion forums about how web designers and UX professionals should or should not be required to know how to “code”. One person asked why they kept getting applications from UX designers who did not “code” (i.e., design from scratch with HTML, CSS, JavaScript, etc.) their own portfolio site. Those applications, according to the original poster, were apparently not good enough because he wanted someone who could design their own site rather than use a WordPress template or theme.

Much of the debate, which I won’t go into now, had to do with whether or not this type of UX person exists – some said this person is a mythical “unicorn” and the poster would be better off looking for UX designers who had a better grasp of psychology (which is also true). My question, and one of my arguments against this UX People Must Code, is that it does not specify the degree to which a (web-based) UX specialist should understand code. (And really, what they’re specifically talking about is HTML/CSS, not Java or .NET.)

I was curious: how much should a UX person learn about HTML/CSS and how fast can they do it? Well, in my own experience, I’ve found that spending a dedicated but serious amount of time learning something difficult (Russian, OpenFrameworks, driving) will not likely get you to mastery, but it will get you somewhere. I wondered if a UX designer dedicated, say, a month of time learning about HTML/CSS would that get them “far enough”?

I typed into my trusty Google search box “learn HTML in 30 days”…and voila! I came across a great website called TutsPlus.com. This site offers tutorials on all kinds of creative and design related topics, included web design and development. Web Development is actually on a sub-site, called webdesign.tutsplus.com. Turns out someone has already created a 30 day tutorial to learn HTML and CSS. And it’s FREE!

Checking it out, and skipping ahead, I was pretty impressed by this tutorial. I like movies and I love learning via video. The tutorial eventually has the pupil try to skin and recreate a website from a PS template. I became inspired to try something similar. Except I didn’t use a template. I used a page from a real website. It was an Etsy tutorial on how to sew a skirt. (I did make my own skirt, eventually, too.)

I’m still working on it, but I’m over halfway finished. The sidebar is a little bit tricky, so I’m taking a break. I’m using the 960.gs grid in 16-columns, and a few HTML5 tags. There’s not much need for CSS3 yet, but I think some of the buttons will need some styling for gradients and corners. It’s been fun, but I’m not sure I’d want to do it everyday. (Maybe, though…if I had more practice.)

*****

The funny part, is that the part of my brain that is working hard to format an HTML page and troubleshoot what could be going wrong with the CSS does not feel like the same part of my brain that comes up with UX inspirations and designs, and makes the associations between how a person would use a system with what the system offers. More on the Coding Designer later. For now, here’s a screenshot of my sample Etsy project and the real Etsy webpage. There’s still quite a lot of tweaking left to do, but you can see how it’s coming together.

My version of an Etsy webpage
My version of an Etsy webpage
Etsy.com Sew a skirt in an hour
Etsy.com Sew a skirt in an hour

JS Timeline interaction from WNYC

Found this today on Twitter. Can’t wait to try it!
“WNYC Timeline example http://wny.cc/JfeOBU ~ code: http://bit.ly/IY62fw ~”

Here it is on git: A beautiful vertical timeline made with Tabletop.js, Isotope.js & Handerlbarz.js. A collaboration between Balance Media and WNYC/John Keefe.
https://github.com/balancemedia/Timeline

Sketching!

With a little downtime at work, I’ve been catching up on some nice UX articles online. Here’s one I found about storyboarding iPad transitions using sketching called “Storyboarding iPad Transitions” by Greg Nudelman. The article calls out 7 principles that can be applied to storyboarding iPad transitions.

  1. Component Relationship (background-foreground)
  2. Illusion (motion perception and perceptual constancy)
  3. Exaggeration (highlighting states, actions, and changes in state)
  4. Staging (camera view, lighting, focus)
  5. Acceleration and Deceleration (slow in and out)
  6. Metaphors (using real-world analogies to convey complex digital events)
  7. Simplicity (avoiding noise)

Actually, I wish I’d seen this article about 3 months ago as it’s directly related to the mobile project I’m currently working on. I did create a lot of sketches, on Post-Its(!), but I didn’t think so much about documenting the transitions as much as focusing on the user flow, which is what I’ve posted examples of below.

Here are some examples of what I did:

There’s more available here.

The article really makes it sound like this is a fairly complicated process; a lot of work. But, I think it would be very helpful, depending on your project. Particularly for off-shore development. Unfortunately, my project has simply too many screens to efficiently even sketch the interactions out, let alone wireframe them all. I hope I get to try this out on another, smaller project.