The origin of personas

The Inmates Are Running the Asylum, published in 1998, introduced the use of personas as a practical interaction design tool. Based on the single-chapter discussion in that book, personas rapidly gained popularity in the software industry due to their unusual power and effectiveness. Had personas been developed in the laboratory, the full story of how they came to be would have been published long ago, but since their use developed over many years in both my practice as a software inventor and architectural consultant and the consulting work of Cooper designers, that is not the case. Since Inmates was published, many people have asked for the history of Cooper personas, and here it is.

In their book, Fire in the Valley, authors Paul Freiberger and Mike Swaine, credit me with writing the “first serious business software for microcomputers” as far back as 1975. Like so much software of the time, it was terribly hard to use, and its real power was in demonstrating that making software easy to use was harder than everyone thought. Despite my commitment to making software more user-friendly, it wasn’t until 1983 and about 15 major business and personal applications later that I began to develop a more effective approach.

I was writing a critical-path project management program that I called “Plan*It.” Early in the project, I interviewed about seven or eight colleagues and acquaintances who were likely candidates to use a project management program. In particular, I spoke at length with a woman named Kathy who worked at Carlick Advertising. Kathy’s job was called “traffic,” and it was her responsibility to assure that projects were staffed and staffers fully utilized. It seemed a classic project management task. Kathy was the basis for my first, primitive, persona.

In 1983, compared to what we use today, computers were very small, slow, and weak. It was normal for a large program the size of Plan*It to take an hour or more just to compile in its entirety. I usually performed a full compilation at least once a day around lunchtime. At the time I lived in Monterey California, near the classically beautiful Old Del Monte golf course. After eating, while my computer chugged away compiling the source code, I would walk the golf course. From my home near the ninth hole, I could traverse almost the entire course without attracting much attention from the clubhouse. During those walks I designed my program.

As I walked, I would engage myself in a dialogue, play-acting a project manager, loosely based on Kathy, requesting functions and behavior from my program. I often found myself deep in those dialogues, speaking aloud, and gesturing with my arms. Some of the golfers were taken aback by my unexpected presence and unusual behavior, but that didn’t bother me because I found that this play-acting technique was remarkably effective for cutting through complex design questions of functionality and interaction, allowing me to clearly see what was necessary and unnecessary and, more importantly, to differentiate between what was used frequently and what was needed only infrequently.

Plan*It was eventually sold to Computer Associates and released to the public as SuperProject, which became a critical and commercial success. For several years it was the dominant project management program for personal computers, and its design is the model for today’s market leading product from Microsoft: Project.

Another product I designed using a similar technique was a visual programming language code-named “Ruby.” I eventually sold Ruby to Bill Gates, who married it to his QuickBASIC language to create Visual Basic, the paradigm-defining product that presented an old language in a revolutionary new way. I designed it for a single user loosely modeled after an IT Manager working at Bank of America’s world headquarters in Concord, California.

In 1990, instead of creating another program, I offered my software design experience to my colleagues as a consultant for the first time. I quickly learned that consulting is quite different from entrepreneurial invention. Previously, I just built what I thought was right. Now I found that I had to persuade my clients before they would follow my lead or see the benefits of my ideas. This imperative for communication eventually impelled me to formalize the notion of personas.

In 1995 I was working with the three founders of Sagent Technologies, pioneers in the field of what is now called “Business Intelligence” software. During discussions with them regarding interaction design for their product, I found myself continually engaged in a circular dialogue. I would ask them for a specific example of how someone would use their program. The answer would invariably follow this characteristic pattern: “Well, someone could create a crosstab of sales information…but it could be a chart, or if it were marketing data they could present it as a table. They could do anything!” It was almost impossible for those brilliant, logical programmers to conceive of a single use of their product when it was obviously capable of so many uses. In frustration I demanded to be introduced to their customers.

At the time, the company was new, and the product wasn’t yet released, but the founders had well-established business relationships from three previous companies. Alice Blair, Sagent’s head of product marketing, took me on a tour of a half-dozen or so of their intended clients. One of them was a financial analyst for a large university. One was a marketing analyst for a software firm. Some were computer savvy and some were not. I asked them open-ended questions to learn about their jobs and what they were trying to achieve by studying these large quantities of data. Even though the variation among the users was dramatic, a clear pattern emerged after just a few interviews. The users fell into three distinct groups, clearly differentiated by their goals, tasks, and skill levels. Had I been creating the software myself, I would have role-played those users as I had with Ruby and SuperProject, but in this case I had to describe those user models to the Sagent team. So I created Chuck, Cynthia, and Rob. These three were the first true, Goal-Directed, personas.

Chuck was an analyst who used ready-built templates and reports. Cynthia was an analyst, too, and she used similar ready-built templates. But Cynthia also wrote her own templates, which she gave to Chuck to use. Rob was the IT manager who supported both Rob and Cynthia. He could optimize Cynthia’s templates, but he would never originate or use them.

At the next group meeting, I presented my designs from the points of view of Chuck, Cynthia, and Rob instead of from my own. The results were dramatic. While there was still resistance to this unfamiliar method, the programmers could clearly see the sense in my designs because they could identify with these hypothetical archetypes. From then on, I always presented design work using one of the personas, and eventually even the Sagent engineers began to talk about “what Cynthia would do” or “whether Chuck could understand” some dialog box. When the product eventually came to market, its interface was clumsy in places, but it possessed a fundamentally clear, three-faced interaction structure: Chuck’s interface allowed him to select and use ready-built templates and reports; Cynthia’s interface allowed her to design and publish templates; and Rob’s interface allowed him to optimize the performance of Cynthia’s templates without altering their content or behavior. The product was so successful that it defined a new product segment. The company was a success, too, going public four years later.

The effectiveness of Chuck, Cynthia, and Rob as design tools for me and communication tools for the entire construction team was obvious and significant. I began to use personas in all of my design projects, as did the designers at Cooper. Over the next few years, we developed and perfected the technique. It became our secret interaction design weapon. Several people counseled me to keep the notion of personas a secret, arguing that it would give me a competitive advantage. But my reasoning went in the other direction. Personas were so simple, clear, and powerful that it seemed only a matter of time before other practitioners discovered the technique for themselves. When this happened, I would lose my competitive advantage anyway, but if I disclosed what I knew about personas, at least I could receive some credit for contributions to an industry that I loved. This is what prompted me to write about personas in Inmates.

The book was intended to alert managers to the problems inherent in designing software for use by non-engineers. It was never meant as a “how-to” book for interaction designers. However, at the time the practice of interaction design was relatively unknown, and my methods in particular were so unfamiliar, I felt it necessary to add some description of the Goal-Directed methodology. My goal was simply to demonstrate that there was indeed some substance to my method: that it was different, that it was effective, that it was real.

I’m tempted to say that personas are counter-intuitive, but it would be more accurate to say that they are counter-logical. I suspect that this is why they originated in practice rather than in the laboratory or in academia. If, responding to the directive design for the user, you follow logic, you tend to canvass the user community, collect their requests for functions, and then provide them a product containing all of those functions. I call this “the sum of all desired features.” There is abundant empirical proof that this solution is only marginally effective at best. The problem is that while logic is a powerful and effective programming tool, it is a pathetically weak and inappropriate interaction design tool.

Many of my predecessors have employed ethnographic user research and created persona-like constructs to aid their designing. Product marketing professionals have also been using persona-like entities for many years to define demographic segments. But personas are unique and uniquely effective.

Personas, like all powerful tools, can be grasped in an instant but can take months or years to master. Interaction designers at Cooper spend weeks of study and months of practice before we consider them to be capable of creating and using personas at a professional level. Many practicing designers have used the brief 25-page description of personas in Inmates as a “Persona How-to” manual, but a complete “How-to” on personas has yet to be written. I hope someday that one of the very accomplished architects at Cooper will write that book because they have developed the technique to a degree of sophistication well beyond my seminal efforts. I look forward to contributing to it.


dane van dyck
wow, cool story; It really evinces the power of original thought!
I remember seeing tutorial notes from CHI'93: Verplank, W., Fulton, J., Black, A., Moggridge, W., "Observation and Invention: The Use of Scenarios in Interaction Design", CHI Tutorial (1993), ACM That would be a nice addtion to the history of the method, showing some parallel development. That described "characters", personas that were created based on observing potential users, and then these were used for creating user scenarios. I sincerely regret that I didn't keep my copy. It's probably quite difficult to find nowadays as it was probably distributed onlly as paper copies. And looking at the presenter list, I also regret I wasn't there to attend the tutorial!
Insightful written piece you've here. I did a write up pllosnarey on this topic some time ago, and I wish I had your content page as a resource back then. Oh well. Thanks again for this blog post.
lou suSi
Its amazing how many organizations I've worked at over the years out here in the Boston area that take the time, energy and resources to develop amazing rich persona documentation to simply put it up on the wall as a gentle reminder without knowing how ( or even attempting ) to actively utilize the persona work in a tactical way to help inform, guide and improve the design work. I don't know why this is — I can only guess that there's something about the playful nature of 'acting' through an experience that must feel too playful and frivolous for most corporate contexts, which to me is a huge shame. I think I 'get it' and understood a while back how critically insightful and useful it is to leverage personas as a means to inform 'what it might be like' to use a designed experience while talking or walking through an experience in the shoes of a human user. I know I can quickly move in and out of various imagined ( but well-informed ) user mindsets while I'm designing at my desk. And there's the whole 'But, is that what Amy would do in that scenario?' kind of conversation that comes up in meetings. But that's not the full power of how personas can inform and guide our design thinking. It helps that I've had some experience in performance art. Sometimes immersive, intervention-based performances at that. And I am also aware of a colleague's graduate work and writing in UX and Theater — Tracy Lepore ( ) that touches on the subject from that interdisciplinary vantage point. Anyhow, I've been trying to work on more and more awareness-based activities and thinking in my teaching. Students seem to get a lot out of engaging in more of these persona-informed, first-person multi sensory methods of design thinking — but it takes a lot of building up on your own personal self- and social-awareness first to then engage in deeper persona-based methodologies. I've suspected for a while now that most of the UX teams I've worked in treat personas like a checklist item for UX without truly engaging in the full practice and now reading this amazing historical perspective of the origins of personas as a tool for UX really helps solidify and clarify that my suspicions are 'right on' and that we have a lot of work to do to really benefit from this powerful toolset.

Post a comment

We’re trying to advance the conversation, and we trust that you will, too. We’d rather not moderate, but we will remove any comments that are blatantly inflammatory or inappropriate. Let it fly, but keep it clean. Thanks.

Post this comment