Personas Are Design

Shawn Crowley and I recently spent some time at Cooper in San Francisco. Among many interesting conversations during our visit, I had one of those “ah-ha” moments when Alan Cooper was describing his view of personas. I’d read all about personas before, including Cooper’s writings, and Atomic regularly uses them in our software product development practice. (Considering Alan is widely credited with having invented, or at the very least popularized, the use of personas, it might seem obvious that discussing personas with Alan Cooper himself would result in some useful learning. But as with all learning, I believe, it’s not about the teacher, it’s about the student.)

I have previously thought of personas as a source of information to inform and influence product design. Personas were an artifact of research, and a source of information to turn to when designing the information architecture, interactions, and features of your product.

The light bulb went off over my head (rather apparently, I gather) when something Alan said made me see personas as part of the design itself, rather than something you use to create a design. Put another way, personas aren’t research, they are design. When you’re identifying personas, selecting them, fleshing them out, editing them, and prioritizing them, you’re making design decisions for your product. What you leave out, or de-prioritize has as much impact on the design of your product as what’s left in. Who your personas represent, what they care about, what’s important to them—all of these decisions are product design decisions. Personas are some of the earliest product design decisions we make.

Outside of nestling personas more deeply and comfortably into my neural pathways, is this insight valuable? I think it is, and for two reasons. First, it helps you realize the significance of the activity you’re engaged in when developing personas. Even if you didn’t actually produce a persona artifact of some sort, you’re making critical design decisions that will impact the outcome of your product. (Or conversely, if you’re skipping this activity, and have no effective replacement for it, you’re flying blind with respect to what you’re building.)

The second reason it matters to recognize personas are design comes during the development stage of your product. Months into software development you may realize your customer or the product manager is steering the project into features that don’t in fact serve the design (specifically, the personas) you started with. This might be good, or it might be bad, but it sure seems like an interesting thing to give some consideration to. Software development is such an expensive activity that it’s irresponsible to do unless you have a good idea of where you’re going and what you’re building. Keeping your personas around as regular touchstones will help you realize whether you’ve left the original design behind, and help you have that critical conversation with your customer, if so.