Taking the “You” Out of User: My Experience Using Personas

Posted by

The best laid plans…
In 1999, I co-founded a small San Francisco-based start-up called Pyra. Our plan was to build a web-based project management tool and we chose to focus initially on web development teams for our target audience since, as web developers ourselves, we had intimate knowledge of the user group. At the time the team consisted of three people: my co-founder, our lone employee and myself. We considered ourselves to be good all-around developers: competent in both interface and back-end development. We also assumed we were developing our product (called “Pyra” for lack of a better name at the time) for people just like us, so we could make assumptions based on our wants and extrapolate those desires for all users.

At this time, Microsoft had just released Internet Explorer 5 (IE 5) for Windows and we were anxious to use its improved standards support and DHTML in our application to make the interface as whizbang as possible. By limiting our audience to IE 5, we decided we would be able to deliver the most robust application, one that was sure to impress potential users and customers. Later, we told ourselves, we’d go back and build out versions with support for Netscape and Macintosh. So we set to work building the coolest web application we could, taking full advantage of the latest wizardry in IE 5 for Windows. Development was chugging along when Alan Cooper’s “The Inmates Are Running the Asylum” was released and I picked it up. When I got to the chapter discussing the use of personas, I was intrigued. Though I was confident in our approach, creating personas sounded like a useful exercise and a way to confirm we were on track.

Discovering Personas

“Not only were the personas not all like us—our personas wouldn’t even be able to use the system we were building for them!”

Cooper’s personas are simply pretend users of the system you’re building. You describe them, in a surprising amount of detail, and then design your system for them. Each cast of personas has at least one primary persona, the person who must be satisfied with the system you deliver. Since you can’t build everything for every persona (and you wouldn’t want to), the establishment of the primary persona is critical in focusing the team’s efforts effectively. Through the use of personas, the design process moves away from discussions that are often personal in nature (“I’d want it to work this way.”) or vague (“The users like to see all the options on the home page.”) . It becomes a series of questions and answers based on a concrete example from which the team works (“Mary, the primary persona, works from home via dialup four days a week, therefore downloading an Access database isn’t an option.”). In our case, the development of personas helped us recognize that the target audience we’d chosen, web development teams, wasn’t as homogenous as we first assumed. Not everyone who’s involved in web development is gaga for DHTML or CSS—some people on the team might not even know what those acronyms stand for, a simple fact we’d failed to consider up until this point.

Our team stopped working to discuss personas and Cooper’s approach and we agreed it sounded important enough to devote some time to it. As we sketched out our various personas (a project manager for a large company whose corporate standard was Netscape 3, a web designer who worked on a Mac, an independent consultant who worked from home), it became apparent we had made some bad assumptions. Not only were the personas not all like us—our personas wouldn’t even be able to use the system we were building for them! We’d been so blinded by our own self-interest we failed to realize we were building a useless team product. Sure, it would have been great as an example of what we hoped to build, impressive to any engineer or web developer, but a manager might not be able to access it. We were cutting ourselves off from the people who would most likely make the decision to use the tool—and no project team would signup for Pyra because an entire project team couldn’t use it.

We were a month away from releasing the beta version of Pyra at this point, but we knew what needed to happen. We had to go back and redo our application to work for Netscape and IE, for Windows and Macintosh, and in doing so, we needed to reevaluate our tool using our personas (specifically our primary persona) rather than ourselves or the mythical “user” to guide our decisions. So that’s what we did, pulling out all our beloved DHTML and remote scripting so our 37-year-old project manager persona could access the application from her home office in Seattle on a Saturday afternoon. Though the rework delayed our beta release by two months, it resulted in a tool our potential customers could use immediately.

Learning hard lessons

Through the process of developing personas, the mistakes we’d made became clear to us:

Mistake #1: We chose flashy technology over accessibility.
We allowed the geeky part of our personalities, with its lust for the newest and greatest ways of doing things, to overwhelm the decision-making process. Though there was a sense at the beginning that we needed to support other platforms, we let our desire to use the newest “toys” change the priority of doing so. This is a common mistake programmers and engineers make but one which can be avoided through the use of personas. Interestingly, when we redid Pyra based on our personas’ needs, we didn’t lose any of the previous functionality. We only changed how it was done, e.g., reverting to less elegant page reloads rather than DHTML client-side changes. The previous version had only been impressive to fellow geeks like ourselves, but we hadn’t realized that. More importantly, the essential quality of the tool was never lost, but by redoing it, it become available to many more people.

Mistake #2: We assumed users would be more impressed by a robust interface they couldn’t use than by a less elegant application that they could use.
Again, our technical hubris blinded us into thinking that potential customers would be impressed by how we built our functionality, not by what the underlying features were. We let our wants come between our product and our users.

Mistake #3: We thought we were the primary persona.
While we shared common goals with our some of our personas, and though one of the personas we developed was very similar to the members of our team, none of us were the primary persona. This crucial distinction between primary personas and secondary personas forced us to realize the interface we designed shouldn’t be driven by our wants or needs, even as members of a web development team. Defining a primary persona prevented us from releasing our original tool with its accessibility failures.

Less than a month after the beta release of Pyra, we released a second tool, Blogger. Though we didn’t create formal personas for Blogger users, the experience we gained by using personas infused our company’s approach to building web applications. Any time the word “user” was mentioned, questions flew: “What user? Who is she and what’s she trying to do?” Our work with personas increased our awareness of our audience and their varying skill levels and goals when using the application. The use of personas helped move all our discussions about the application, not only those related to the interface, away from the realm of vagaries and into tangible, actionable items. (“It should be easy to create a new blog.” “Easy? Easy for whom?” “It should take less than a minute to get started.” “It should take less than a minute for my grandmother to get started,” etc.) We developed a system of familiar, conversational personas on the fly, focusing on the primary persona without going through the formal process.

In retrospect, some of this sounds like common sense, and yet time and time again I find myself looking at an interface and making assumptions based on how I’d like it to work. Like a recovering substance abuser, it’s a constant challenge for me to refrain—I can always imagine that I’m the user. Even if your budget or timeline doesn’t allow for the development of formal personas, you can still benefit through the use of informal “conversational” personas, like we did while building Blogger. It takes discipline to break the old assumption habit but the more I use personas, the easier it becomes. I’ve carried the lessons I’ve learned through their development with me for the past three years to other projects and engagements; the use of personas resulted in a fundamental shift in the way I approach not only interface design but application architecture as a whole.

For more information

Alan Cooper, The Inmates Are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanity. SAMS, 1999.


  1. When I use personas, they’re always based on user goals or intentions: What is each persona coming to the site to *do*? (We think in verbs when doing this.) Goal-defined personas lead naturally into prioritizing features and describing appropriate interactions. Demographic and psychographic info is helpful as an additional layer of detail and realism on top of these fundamental goals. It’s not essential to understand that Harriet the Home Seeker has 2-year-old twin girls and drives a Dodge Caravan, but it does make Harriet more real in the minds of the project team.

  2. GeoffreyMoore takes a similar approach in talking about “scenarios” and “target-customer characterizations” in CrossingTheChasm (p93 in my paperback)

  3. One think that helped me (I think) understand how other people think and foresee potential obstacles, was the fact that early in my career, I thought computer applications.

    So many things that seemed apparent to me, were no so for the students. User testing experiences I had were similar.

    I believe it is good practice to test and use personas until you develop that way of thinking. And even when you do —testing does not hurt. That does not mean that you have to user test every little assumption you make —If you do not develop some level of instinct over time, you’re in the wrong profession.

    Also, there is a lot of ‘usability’ data that accumulated over hundreds of years —typography, color theory, perception, etc — As they say —those who do not learn from history…

  4. >>Any time the word “user” was mentioned, questions flew: “What user? Who is she and what’s she trying to do?” Our work with personas increased our awareness of our audience and their varying skill levels and goals when using the application.

  5. We use personas and scenario-based design religiously in our organization.

    To piggy-back on Steve’s post above, we’ve found that details about a persona–car they drive, age, number of kids–plays a larger role than making a user real or identifying to what demographic a persona may map.

    The details of a persona may illuminate the most subtle, yet important thing about a user—-user motivation. Motivation can be heavily influenced by environment. This is where personas go and use cases fear to tread.

    In the same way that we remind ourselves that users are not designers and we are not the target users, we should remind ourselves that the user will tell us how much detail is enough for a persona.

    Without a deep understanding of a user’s enviornment and how they work within it, a persona (and a usability expert) can miss key motivators to user behavior.
    For example, a mom with 2 kids and a Dodge Caravan. How might she be different from another Mom persona in which we don’t know that info?

    The Mom with kids persona leads a hectic lifestyle. Her free time is fleeting. Her kids are always into something. She must keep one eye on them even when they are napping.

    She is usually in a hurry and will not have time for sites that require a large time investment. Her goals are practical (perhaps the motivation behind the minivan) and speed-based.
    Her world is much more real and important to her than any “domain” we create.

    This info can help describe a personal goal–“I don’t want to feel like I’m wasting my time.”

    That could have big design implications and help you decide what functions to keep and what to discard.

    For example, it may be nice to have that nifty ESP search function. What better way to improve search results? Surely the users will see value in that.
    But it takes nearly 5 full minutes to read your mind. So, this Mom (a high-priority user) would grow impatient with it–she can’t imagine sitting still that long.
    The ESP search tool should not be included (even if it is cool) because it is too slow.
    But this also opens a new opportunity–how can we reduce the ESP search tool’s search time so it provides real value for our target users?

    Understanding motivations and influencers is key to good personas. How much (or few) details to include depends on when the details stop adding value and no longer matter.

  6. David Gammel asks an interesting question about quantitative demographic data vs. personas. It’s a question we get asked a lot here at Cooper.

    As it happens, the February Cooper newsletter contained an article by Elaine Brechin about this very topic. Here’s a quote:

    “Personas and market segments provide different kinds of information. Market segmentation provides a quantitative breakdown of the market, while personas provide a qualitative analysis of user behavior. ”

    The rest of the article can be viewed at http://www.cooper.com/newsletters/2002_02/reconciling_market_segments_and_personas.htm

  7. Great article. I’m developing personas with my internal Web team for the first time, and I have two questions: If your marketing dept. has already developed personas actually used in print materials (e.g., Mrs. Smith just luvs our product and here’s why she bought it and *how she’s using it*), do you all recommend bringing the same personas to life for user centered Web design purposes, or starting over with new ones, so as not to confuse the two? I’m torn.

    Secondly, how often do you “update” personas, for example, when a new product is developed or a new customer comes along with a different type of user base, such as an older population? Is it ok to constantly update or change your personas or should they be relatively permanent?

  8. Very interesting thread. I found this sentence from the above mentioned ‘Cooper newsletter’ insightful:

    “Personas are a set of fictional, representative user archetypes based on the behaviors, attitudes, and goals of the people we interview in our research phase.”

    So even though standard marketing demographic data plays no major role in creating realistic personas, there _is_ a justification of the validity of the personas in the user research (mostly interviews) that’s being done beforehand. It’s not just based on designers’ assumptions. I think this is an important aspect that often gets left out when discussing the use of personas. For me anyway, it took away some scepsis about the method…

  9. Damon puts that well. That’s the link that I thought had to be there. It seems that personas must be driven by demographic data of your market if they are going to be relevant tools as opposed to the designers ideal users who may or may not exist in enough numbers to keep you in business.

  10. it wasn’t till reading this piece that i had my epiphiny. i thought to myself, “Hey, I am a persona!!!” I am now content with my own identity. Thanks meg.

  11. I’m curious…three years later, how do you feel about using personas? What about the folks who responded back in ’02–have you changed methods?

Comments are closed.