The Long Road to Inventing Design Personas
It’s hard to be simple
If you’ve worked in the software or web industry in the last 20 years, you’ve probably been introduced to the idea of “personas” — hypothetical archetypes — as a practical interaction design tool. Whether you hate or love this idea as a development tool, you can thank me. My book, The Inmates are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanity, first published in 1998, introduced the use of personas. Based only on my 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, but I invented personas over many years in my practice as a software inventor and design consultant. Since The Inmates was published, many people have asked for the history of design personas — so 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 value 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 software products later that I began to develop a more effective approach.
Kathy became the model for my first, primitive, persona.
I was writing a critical-path project management program that I called Plan*It. It was eventually published and became a bestseller. 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, my brother-in-law’s Silicon Valley advertising agency. Kathy’s job was called “Traffic,” and it was her responsibility to assure that projects were staffed and staffers were fully utilized. It seemed like a classic project management task. Kathy became the model for my first, primitive, persona.
Compared to what we use today, computers in 1983 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. It was my custom to do a full compilation at least once a day, usually 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 as I walked. I know some golfers were taken aback by my unexpected presence and unusual behavior. It 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 only needed infrequently.
He fell victim to a common syndrome that I later named “self-referential design,” a malady that personas cure.
Plan*It was eventually sold to Computer Associates and released to the public as SuperProject. It 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.
Over the next four years, I designed and built two more products of similar scope that were eventually published. The design of one of them was dominated primarily by the confusion and egocentricity of my client, the president of the publishing company. He fell victim to a common syndrome that I later named “self-referential design,” a malady that personas cure. He demanded features and behavior in the program that he wanted, even though it would be sold to and used by others. The product and the company failed a few years later.
The second product was a visual programming language code-named Ruby. I eventually sold it 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. Ruby was designed using a method very similar to the one I used on SuperProject. I designed it for a single user loosely modeled after a real IT manager working at Bank of America’s world headquarters in Concord, California. Visual Basic’s enormous commercial and critical success has universally altered the way programming languages are used and designed.
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 even see its benefit. It was this imperative for communications that 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 between 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 Cooper 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 Chuck and Cynthia. He could optimize Cynthia’s templates, but he would never originate them or use them.
Personas became our secret interaction design weapon.
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 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, and as Cooper grew I demanded that all designers on our staff do the same. Over the next few years, we developed and perfected the technique. Personas 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 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 The Inmates.
The problem is that while logic is a powerful and effective programming tool, it is a pathetically weak and inappropriate interaction design tool.
The book was intended to alert managers of the problems inherent in designing software for use by nonengineers. 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 my goal-directed methodology. My goal was simply to demonstrate that there was indeed some substance to my methodology: that it was different, that it was effective, that it was real.
I’m tempted to say that personas are counterintuitive, but it would be more accurate to say that they are counter-logical. I suspect that this is why they originated in practice and not in the laboratory or academia. If, when responding to the directive “design for the user,” you follow logic, you tend to canvas the user community, collecting 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 perfected 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 design personas are unique, and are 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 The Inmates as a persona-how-to manual, something it was never intended to be. I hope someday to be able to write that how-to but so far the press of work has prevented me. In all likelihood, one of the very accomplished designers at Cooper will write the book instead of me because they have developed the technique to a degree of sophistication well beyond my seminal efforts. I’m looking forward to contributing to that book.
This essay was originally published in the summer of 2003.
