Personas need a purpose: why you shouldn’t try to make personas that cover the whole company

(and why data annoys me, plus a few bonus tidbits from my time at Amazon.com)

My friend Benjamin asked a great question when I published my recent article on personas. I said in that article that one of the reasons an existing set of personas might not have worked could be that:

“They were probably created for the entire company, a big bunch of products or services, or a big division in the company, and not for any individual projects or products. This never works well.”

And he asked:

This seems to be a major issue in many companies when trying to implement personas. How do we make companies understand that personas have to be more product- and/or project-oriented?

Here’s the punch line:

Personas that are broad enough to cover a company, organization, or big product end up being too vaguely described to be as useful as personas should be.

For YOUR company or organization or huge product? Here’s the short answer. Tell your bosses that personas for everything tend to cost major money (data collection and analysis is pricey) and end up being ignored. Instead, try a skunkworks project creating ad hoc, or, as I call them, “Alignment Personas” for a single, well-defined project that has clear business goals attached to it. If it works, hey presto, you have proof personas work for your company. If it doesn’t, you don’t ruin personas forever in the minds of your colleagues (though it may be a little late for the latter).

Let’s start the longer answer to creating personas with a story. I was at Amazon from 2002–2005. I wouldn’t trade that experience for the world. It was like an elite grad school focused on technology, the web, and ecommerce. During that time, I was also elbow deep in writing the book I co-authored with John Pruitt, “The Persona Lifecycle: Keeping People in Mind Throughout Product Design.” We had started the book in 2001, so by November 2002, when I started at Amazon, I was all about personas. I came roaring into my new job sure that personas were the answer to everything.

Amazon is an intensely data-driven place (shocker, I know. I’m sure you’ve never heard that one before). My new awesome boss Larry Tesler helped me make connections with the equally awesome Diane Lye who ran the Data Warehouse. We created a killer team of geniuses to figure out how to create personas for Amazon.com. We had access to all the data. We worked on “The Amazon.com Personas Project” for over six months. I was well on my way to being one of the top experts on personas in the world. And we failed.

Anyone savvy in all things startup knows that failure is part of the process — it’s part of success. And this failure triggered a new way of thinking for me which evolved into the approach I use to create and use personas today. That didn’t really help us at the time though.

Why did the Amazon-wide personas fail? Because we had so much data that we couldn’t quite figure out how to moosh and smoosh it all into useful personas, and because we weren’t willing to sacrifice accuracy for precision. Whatever persona candidate categories and candidate personas within those categories we came up with, they were inevitably too broad to be helpful.

Data is annoying.

Data began to piss me off. It’s like a huge, lazy, bad-tempered walrus. If it’s there, you have to deal with it. But good luck when you try to get a handle on it or make it do something, and God forbid it notices that you’re messing with it. It will haul itself around and bite you in the ass. Also, data is by definition describing what happened in the past (though that’s not necessarily true of a walrus). Sure, there are fancy ways to draw good guesses about the future out of it. But it’s always describing customers you already have, and not necessarily those you want. (Cue fury from data people … and … GO!)

The Trap of Useless, Data-Driven Distinctions: Spearfishers vs. Browsers

Let’s explore just one example which is fairly representative of all the experiments we did: spearfishers vs. browsers. This is a great example because it’s pretty obvious, it gives nothing secret away, and it’s epically useless as a way to think about online shoppers.

Of course the data showed that some people were spearfishers and some browsers. In other words, some people came to Amazon knowing exactly what they wanted, searched, found, and bought. Others would noodle around on the site to see what they could find, looking to get attracted to something, or discover new products. Unsurprisingly, it also showed that many shoppers weren’t always one or the other.

We could create various personas of spearfishers, browsers, and combinations who were either or both during different shopping sessions. And we did. All were backed by data.

And then we tried to figure out how they were helpful.

How would you use a spearfisher persona to make any meaningful decisions on Amazon? Even then, the site was designed to enable both activities and to entice each to do the other. How would you use a spearfisher persona to help design a UI? I’m sure some of you reading this can argue for the value, but believe me, even knowing deep psychographic, demographic, and behavioral data about spearfishers really wasn’t helpful in making design decisions.

A related aside: The best memory I have about this exercise was that, at the same time, rumor around the office had it that at some point some branding company had done a survey to ask people to describe Amazon as if it were a person. The answer that came back? If Amazon were a person, it would be a 35-year-old white guy wearing glasses, a button down, and Dockers. This was also information that was both true and epically useless. However, it did, and still does, remain useful in totally cracking me up.

So maybe we should try personas based on something other than bias towards one or the other approach to shopping. And we did. We tried ages, education levels, demographics, psychographics, behavior on the site, and statistical combinations of all of these things. We made matrices and spreadsheets, used sticky notes, and wrote sequel queries. We had printouts a mile long. We met and worked our brains off.

Remember, personas are not the same as personalization. The ridiculous amount of data was and is helpful in creating personalized experiences — so that I see different recommendations for products than you do. Personas are fake people who embody data (to some extent) and they are tools for people who design experiences.

Beyond this you’ll just have to trust me, and trust that there was no better data set or data team in the world working with me, along with a small but killer user experience squad. We kept trying.

While our big persona effort was struggling, elsewhere smaller personas were popping up and thriving.

While we were working on the big personas (which we never finished), I worked with several smaller product teams, helping with very early stage customer experience strategy and design (i.e., zeroing in on what they had been asked to design and build, and the best ways to do so). For example, I worked with both the loose diamonds and the auto parts teams to create the interfaces for buying each on Amazon.com. No, these are not project code words. These were teams working on user interfaces for people who wanted to buy loose diamonds or auto parts on Amazon.com.

At the time, it didn’t occur to me that it was truly bizarre to:

• expect people to buy loose diamonds on Amazon.com
• expect people to buy bumpers for ’67 Chevys on Amazon.com
• design the experiences for each so that they made sense with all the other Amazon UIs, made sense with respect to their particular products, and made sense with respect to each other (just in case someone zipped over to Amazon to buy a 1997 Honda Civic carburetor, a two-carat, cushion-cut diamond with minor inclusions, and a copy of “What Color is your Parachute” in a single session).

(An aside here: One of the most head-scratchingly amazing things that I learned at Amazon is that often Jeff Bezos’ ideas make absolutely zero logical sense to me, but that he’s also usually right. It was annoying until I decided that it was like watching — and somehow participating in — a Sherlock Holmes story. He always makes it make sense in the end, so enjoy the ride.)

In fact, these smaller projects were really where the Alignment Personas idea was born. John and I and the whole UX community were all about data-driven personas at that time. Our whole book pivoted on us figuring out a step-by-step process to create personas using data. But I was in this weird position of:

• working on data-driven personas for all of Amazon (so I knew basically what data types were available)
• having access to the best and biggest data set on earth (at that time)
• not having data-driven personas for all of Amazon (they weren’t done yet)
• working with two teams who were creating UIs for selling new product types on Amazon (there was no data on how people shopped on Amazon.com for diamonds or auto parts, because we hadn’t done it yet)
• being sure that personas are always a good idea for teams trying to create together (once you see them working, you can’t really live without them … the words ”user” and ”customer” cause allergic reactions because of their annoying and dangerous in-specificity)

So instead of using data, the teams and I created quick, ad hoc personas (which I now call Alignment Personas). We created personas like these (and these aren’t actually the ones we created. Those are secret and plus they were so long ago that I don’t actually remember them completely).

For auto parts, they were probably something like:

• “Charlie ’57 Chevy,” the guy who is all about his particular car, and it’s a special car that’s hard to find parts for
• “Kelly Kia,” the gal who has an inexpensive car she likes to maintain herself
• “Andy Auto Parts,” the guy who owns an auto parts store in some remote town who doesn’t keep a lot of stock on hand and sometimes has difficulty getting what he needs in a timely manner from his suppliers
• And others …

For loose diamonds, they may have resembled:

• “Shelly Sparkles,” the gal who can’t wait to get engaged and likes shopping for the perfect diamond for when that time comes
• “Bob Big Diamond,” the guy who is ready to pop the question and wants to get the biggest diamond he can for his money
• “Corey Careful,” the guy who has taken it on himself to become an expert in the Four C’s of diamond quality so he is sure to get a great stone
• And others …

These personas helped, and they helped fast. They were very precise (Shelly was a girl, not a girl or a guy). They made sense as targets for the teams. And they had opinions on the features that would help them the most.

Meanwhile, back in the land of enormous data …

The all-Amazon, data-driven personas crack team of geniuses, led by yours truly, kept hitting barriers. We could try to sort and re-analyze and statistically re-assess and model and segment to our heart’s content, but we couldn’t really find anything useful. Remember, we weren’t trying to come up with marketing personas (personas to help us decide how to market Amazon to people by putting ads and messaging in various places). At that time, there was no Amazon marketing (legend has it that Jeff Bezos got rid of the marketing team and used the money to create Super Saver Shipping, which was free shipping on any order $25 or above).

No, we were trying to create product personas, which are personas that help a team decide which features to build and how to design those features. A very different goal. Marketing personas help you figure out how to appeal to people to get them to the site in the first place. Product personas help you figure out how to get them to do things after they’ve arrived.

No matter what we tried, we could not make personas that covered all Amazon shoppers in some useful, usable way.

The genius of Alan Cooper: personas must be precise, not accurate

In the book that changed my professional life “The Inmates are Running the Asylum,” Cooper insists that useful personas have to be precise (in other words, a persona has to be male OR female, a professional horse jockey OR the manager of a network operations center). This is why “middle-aged, ex-urban women with children” can’t be a persona, but Elizabeth, who lives in Orange, New Jersey, and has two kids named Ethan and Emily can. And because they have to be precise, they can’t really be accurate: you can’t accurately describe a set of data using a single person. This is probably the biggest reason we couldn’t create data-driven personas for all of Amazon. Amazon’s love for data is a love for accuracy. Any persona we created using that data, if it was precise enough to be a persona, couldn’t be accurate enough to be considered data-driven, and therefore acceptable.

Without precision, personas aren’t personas. Any help they could give all of the Amazon teams couldn’t happen.

But the loose diamond personas and the auto parts personas were precise. We were free to create them because:

a. there wasn’t a lot of applicable data
b. no one super important was really paying that much attention
c. we had no time — these features simply had to be designed and launched superfast (why, I’ll never understand, but there you have it)
d. the product teams were hungry for help

So we created the non-data-driven Alignment Personas superfast (in a couple of meetings), made our best guesses about which ones were more or less likely to actually buy these things on Amazon, and off we went, getting creative about designing an Amazon-appropriate shopping experience for each.

And … it worked.

The teams didn’t flail. There were no “that wasn’t what I asked for” moments in design reviews. We flew fast under the radar and we launched. And what we launched sucked less than everyone expected it to. Other teams started asking how we managed to pull those projects off without major injuries. And we showed them.

Little, specific, precise, ad-hoc, assumption-based personas aligned the interdisciplinary teams provided otherwise missing north stars and a common language. They were there to speak when we wondered which features would be most helpful. They depoliticized. They helped. They may or may not have been somewhat accurate — and it didn’t matter either way. The resulting user experiences made sense, they had internal consistency, and they worked. They were little microcosms within the vastness of Amazon.com: each was “Amazony” in its own ways and unique in its own ways.

Long story long …

The data-driven personas for Amazon.com were never born. But many, many sets of project-specific personas were. The latter were successful. This is why I always recommend that people start with small, under-the-radar persona efforts. See if the process works first (it usually will), and then, you can show personas with some results, like a UI that sucks less than everyone expected. This often creates a pull in your organization. People will come to you and ask you to help them create personas for their projects. And pulls are always vastly more successful than pushes (see my other article for why personas that are thrown over the wall never work).

I think the magical “alignment” part of Alignment Personas comes the process of creating Alignment Personas together. It’s the journey, not the destination. More on that in a future article on the process.

On the other hand …

There are several exceptions to the big-persona-efforts-never-work argument. For example, the data-driven Windows Vista personas my co-author John Pruitt helped to create for Microsoft in the early 2000s absolutely worked. And I have no idea how he really managed that. I do know he had a lot of money to work with, which never hurts.

Another major exception? The Zillow personas. But they were created long before Zillow was big. In fact, they were created before Zillow was launched.

Please keep sending me questions about personas. I find them inspiring and I’m hankering to keep writing down what I know, one chatty article at a time.