Personas & the Persona Lifecycle book in an article…on MSDN!

MSDN is the Microsoft Developers Network, and an article on personas showed up in their MSDN Magazine. Wow. Even coders are talking about the value of personas! How cool is that, I ask you.

Well, for ME it's cool anyways.

And the authors, Dr. Charles B. Kreitzberg and Ambrose Little, even writing for tech guys who tend to be very data-driven, even approve of quick-and-dirty personas. Kreitzberg, who is the CEO of Cognetics (a company that does usability and ux consulting) wrote the first part of the article, which included this delicious nugget:

Personas do not need to be complex to be useful. I typically begin by creating brief outlines of personas based on conversations with people who know the audience well, such as salespeople or customer service staff. I call these personas "assumptive personas" because they are not based on actual data.

We used the term 'assumption personas' in the Persona Lifecycle book too...now I like to use "Ad Hoc Personas" (which Don Norman used in his Personas & Empathetic Focus article) because really, they aren't based so much on 'assumptions' as they are on embedded knowledge that exists in an organization.

Ambrose Little, who is a software developer, wrote the second half of the article...and I'm even more fascinated by what he has to say. I've of course thought a lot about personas from the User Experience perspective, which Kreitzberg does a wonderful job of articulating. But hearing it from a dev dude is fascinating to me, because for years one of the challenges has been to help devs understand that even a tool this 'soft' can be incredibly helpful to them.

I love this quote:

...if you find yourself in trouble, which happened to me recently, where you have tons of prickly issues poking out of your design, it may just be that you need to zoom out and attack the problem anew from your persona's perspective. Sometimes it's hard to break old ways of thinking about design, and using personas can help you reformulate your approach. In my case, doing this helped me to see that we needed to somewhat dramatically alter our approach in terms of presenting essentially the same functionality to our target audience.

There's still a sort of slightly antagonistic thing that can happen between UX people and developers, which is interesting to me as someone who is a student of intra- and inter-team communication and the problem of focus in companies. The deal is, I think, that everybody is just trying to get their work done. Especially devs, who have typically been yanked around by ever-changing, random-seeming specs for years. They, after all, are the ones who somehow have to translate the chaos into a product that works and sells. Not so easy.

But when it comes down to it, everyone wants the same thing. Cool software that people like, and use. Devs don't want to create crap. They want people to use their stuff. And I like that Little is saying 'hey, this can help.' That's really what it all comes down to.

He also talks about 'dictatorial specifications,' which is a phrase I'm now officially stealing because I love it. Reminds me of Avinash Kaushik's HiPPOs (Highest Paid Person in the Organization:

...even in cases where the team members are committed to human-centered design, personas can help explain what might otherwise appear to be dictatorial specifications. I've seen this happen more than once, where a design specification was questioned because it didn't make sense to some people on the team. They were looking at it from their own, seemingly intuitive perspective, but the solution wasn't being built for them. The personas provide a known, concrete reference point to explain why the spec is the way it is, which takes the focus of the discussion away from what makes sense to individual team members (or what they prefer) to what makes sense for the people you are building for.

The most astute comment in the article is, of course, this one:

An excellent resource to help you understand personas and their construction is the book The Persona Lifecycle: Keeping People in Mind Throughout Product Design by John Pruitt and Tamara Adlin (Morgan Kaufmann, 2006).

All quotes are from here.

User is a four-letter word: the cow argument

The word "user" is such a bad word. And, by the way, so is the word "customers." They are confusing, arbitrary, totally flexible and, worse, a great excuse to never think about the real people who use or buy or enjoy or hate your products. More stakeholders at more companies ignore real people by talking about "users" and "customers" than I care to count. What's the best way to convince people you are paying attention while ignoring everything outside the glorious gray walls of your corporate headquarters? Throw the words "users" and "customers" around. This posting is the cow example, with a nice dollop of Dr. Seuss. I'm sure there will be more postings on this topic, because I am positive I will continue to be annoyed about this and will be forced to vent this frustration in the form of various analogies.

Think of a cow. Got one? Now imagine that we are in conference room full of people and I've asked everyone to think of a cow. Is everyone on the same page?

Arguably, yes. After all, I didn't just ask them to think of an animal, or even a barnyard-type animal. I asked them to think of a cow. So everyone is thinking about the same thing, right?

Well, what color is your cow? Where is it hanging out? What is it doing? Is it fat or thin?

What about the other people in the conference room? are all of their cows similar to yours, or slightly different? Picture the little imaginary herd that all of you have created together. We've probably got some brown cows, some black and white jobbies, maybe a black one. Some are laying around in the distance, some are up against a fence nibbling hay out of our hands. Some are in a barn, some are hooked up to milking machines. They're fat, they're thin. They're cute, they're gross, they're something familiar, they're completely foreign. They're all of these things all at the same time.

So everyone in the conference room thinks they are thinking about the same thing. But what if someone asks about the hooves of the cows? One cow probably hasn't had its feet looked after in a long time. Another spends most of its time indoors and her hooves get irritated by the cement floor of the barn. Yet another has shiny hooves that are regularly rubbed with organic linament by her proud owner. Each cow is different in her details, and each cow-imaginer can easily zoom in and argue for the importance of his or her cow's hoof details.

Companies do this all the time, every day. Everyone thinks they are thinking about 'the user.' Guess what? Everyone's concept of the user is slightly different. These differences are further hidden by slightly more detailed language, like 'the administrator' (talking about users in terms of roles) or 'the early adopters' (defining segments of users).

So long story longer, this is why personas are so important. And this is why I'm convinced that, in a way, it doesn't matter who your persona is as much as it matters that you have one. The lack of shared focus between a team of people who are all working on the same product can be so detrimental that it can trump any 'bad' effects that could be caused by using the 'wrong' persona. In other words, even if they are building a product for cows, if everyone focused on the exact same horse to build the product, they'd be better off than if they were all focusing on different cows. Why? Because at the very least, the resulting product would make sense end-to-end.

Highly-quotable, professionally-worded conclusion you should use in your next meeting with your boss: A product built to make sense to a single horse is probably better for cows than a product that tries to make sense to a huge variety of cows. Well, especially if that product is software or a web site. Which would be weird, but there you have it.

One last thing:

If I ask the same conference room full of people to picture a brown cow, a pretty chubby one with a swayed back and a full udder, chewing peacefully on a mouthful of hay in a large paddock that has a few other cows in it, flicking its tail against an annoying horsefly, you're probably willing to give up your original cow and start thinking about mine. It's not such a big deal…it's still a cow, and if I tell you that I've done some research and most of the cows in our target market are paddock-dwellers with swaybacks and active tails, you'd believe me.

Now, when we start to talk about the barnyard features that we should build to support our cow's hoof-related requirements, all of us can zoom in on this cow's hooves and make some sensible decisions. We won't end up building hoof features for indoor cows and udder features for outdoor cows.

By the way, in my experience, stakeholder-type people aren't terribly attached to their own cows. As long as they get to say 'hey, this is what my cow looks like', and they get to add their opinions into the mix, and they get to hear the relevant cow-data, they're pretty willing to give up the black and white for brown, the barn for the paddock, and the oats for the hay.

User is a four-letter word. But cow is not. And neither is "Sarah, the spendthrift."

Anyways, I could have avoided typing this whole thing and simply provided this excellent quote on user experience by one of the pioneers in our field, Dr. Seuss:

A moose is asleep.
He is dreaming of moose drinks.

A goose is asleep.
He is dreaming of goose drinks.
That's all well and good when a moose dreams of moose juice.
And nothing goes wrong when a goose dreams of goose juice.

But it isn't too good when a moose and a goose
Start dreaming they're drinking the other one's juice.

Moose juice, not goose juice, is juice for a moose.
And goose juice, not moose juice, is juice for a goose.
So when a goose gets a mouthful of juices of moose's
and moose gets a mouthful of juices of goose's,
They always fall out of their beds screaming screams.
SO…

I'm warning you, now! Never drink in your dreams."

- Dr. Seuss's Sleep Book, Theodore Geisel, pp 42-43.

More on personas. I guess it was inevitable.

After writing a <a href="http://www.adlininc.com/what_i_do/books_articles/2007/03/the_persona_lifecycle_keeping.php">gigantic book</a> on personas, you would think I'd be completely out of things to say on the topic. But no. There's more. Like, for example, the things I have to say about the book itself, and why it's so loooooong, and why that ended up being a good thing for most people.

When John and I started writing our book, we were sure that at any moment someone would beat us to the punch. We started writing it in 2001, after all, and by then Cooper's book had been out for almost two years. And a note about Cooper: we kept our project 'under the radar' until it was almost done, and then Cooper himself was invited to read the manuscript by our publisher. He suggested a few changes, which we happily made, and he was very supportive, even though our method is different than the Cooper method. He's an awesome, brilliant guy.

Anyhoo, back to 2001. Everyone was abuzz with personas excitement. That very excitement was really what led to our book. We conducted two workshops at UPA in 2000 and 2001, which were very well received, and we were approached by Diane Cerra from Morgan Kaufmann to write the book. She had heard about us from Jonathan Grudin, who is on MKP's advisory boards. The advisors keep their ears to the ground to let the publisher know who is doing good work in new areas, so the publisher can pounce and ask them to write books.

We laugh when we look back now. At that time we were also working with Holly Jamesen, who moved on to bigger and better things before we wrote the book. The three of us were absolutely sure it would only take us a few months to write the book. After all, we just needed to write up our notes. We had done so much work for our workshops that we already had the lifecycle model figured out. We bragged that we could do it in 6 to 9 months.

Ha.

Four years later, John and I were still slaving away every weekend at the Bellevue Public Library. We opened and closed the place. We had an organized scam to make sure we could get one of the study rooms for our own private use all day long. We had it down to a science.

Why did it take so long? And why write a blog about it taking so long? Well I'm glad you asked. It took so long because both of us had been involved in, or heard about, or seen, a persona effort that failed miserably. Many of them actually. And the more we dug and the more we worked, the more we realized that the devil is in the details in a major way when it comes to personas.

And that's why the lifecycle turns out to be so valuable. Because it's not just about creating personas. It's about keeping them alive and actually using them to do good work. And that's the hardest part.

There are lots of ways to create reasonable personas. In fact, most of my consulting business is based on the amazing value of ad-hoc personas, which do not require any research (gasp!) and can turn around a product strategy within a day or two. Using good, well-created personas is another thing entirely.

This is what I told myself, and still tell myself, when I think about the sheer volume of our volume. It became far larger than the 250-page guide we initially envisioned. It became a reference book that you can (and should) skim at first and return to when you get into a persona-based conundrum.

So here's how to use our book:

• Read the acknowledgments. They are both amusing and touching.
• Read Alan Cooper's intro. it's great. More on the whole Alan Cooper connection in another posting, coming soon.
• Skim chapter one. It's got great stuff on where personas came from, and some good ammo if you need to convince others in your company that personas are a valid method.
• Read chapter 2. It's short. And it sets up the whole lifecycle idea.
• Skim chapters 3-7. These are the meaty, how-to-actually-do-it chapters with instructions for practical methods...and suggestions for how to predict and avoid roadblocks.
• Flip through the invited chapters. They have wonderful insights, but they are outside of the main content of the book. The most readily practical chapters are the one on Reality and Design Mapping, which describes a method that I use all the time. If you are a marketer, check out the last chapter on personas and brand.
• Remember where things are. And remember that when a persona-related question burbles to the surface of your brain, there's likely to be an answer for you in the book.

So there. That's why the sucker is so freaking long. And that's how to use it. More on personas soon. Sneak peek:

It's a new persona era out there.

• People know what personas are, kinda.
• Many have tried to create them, or hired people to create them. Diatribe on hiring external folks to create your personas for you coming soon.
• Many have been totally psyched about personas and then completely crestfallen when the personas 'don't work.'
• Personas are still one of the best tools I know of, and I know of a lot of UX tools.
• The big secret is that the personas themselves don't really matter, and they don't even really need data to help organizations. They need data to help organizations build great products, but they don't need data to help the organizations themselves. And that's a huge deal. And heresy. And worth a longer discussion.
• There is hope.

Stay tuned.