Boxes And Arrows : The Design Behind the Design

Taking the "You" Out of User: My Experience Using Personas

by Meg Hourihan on 2002/03/26 | [15 Comments]

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

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.