I’ve never been completely convinced that personas are a valuable design tool. And I think that’s because I’ve been confused all along.
To me, personas are the total sum of silly names, stock photography and forced lists of likes and dislikes. The act of creating the personas is worthwhile because I solidify in my mind who our user base is, but the personas themselves are not.
But having just read Jared Spool’s blog post titled, Personas are NOT a Document, I’m realizing now that it’s not the personas I have a problem with. It’s the manner in which they’re introduced to an organization.
Introduced. That’s really the crux of it. Personas should need no introduction at all. They should be the synthesis of experiences with real people that the project team — the whole project team, not just designers — come to know and love over the course of time, through a variety of ethnographic research techniques. When you attempt to convey a person’s intricate, inconsistent personality and abstract goals on a static piece of paper, of course they’re going to come off as one-dimensional and fake. And it’s that oversimplification that I’ve always had such a problem digesting.
So how do we take these documents to the next level so that they becoming meaningful, usable, and multilayered — not staid one-sheets that get pinned up on the wall and never referred to again? Or perhaps it’s the documentation of a persona that immediately renders it useless.
I freely admit to using online dating services, even though nine times out of ten the people I meet in real life are almost nothing like the people they appear to be in their templated profiles. The question-and-answer approach to these profiles forces us to consider things we don’t normally think about and may not be particularly important to our personalities. For instance, the service requires that I type at least 250 characters about my idea of the perfect first date. The medium values consistency over personal expression. In all honesty, my perfect first date is simply being able to stand the person sitting across from me :) I don’t have high expectations of love at first sight and dates seen in movies. But when forced to make up an answer to a pretty unproductive question, I do just that — make up the answer. That I don’t expect a first date to be perfect says much more about me than my desire to have drinks, dinner and a walk along the Hudson.
The users of our products are living, breathing human beings. Their persona is the role that they assume when they’re using the product. But it can be difficult to stomach one without the other. When you communicate solely about a person’s public face, it naturally feels fake and uncomfortable. While creating a persona document, we attempt to mitigate this by fabricating the customer’s personal life or characteristics outside of what we observed. The school they attended, their hobbies, the quote they live by. The persona can become laughable instead of instructive. And we stop connecting to them as real people whose lives we’re trying to improve.
Two members of my design team, Liya and Arti, fluently use their persona names in conversation. When talking through a piece of functionality or a complex design problem, they almost never make statements like, “the user would…,” but instead say, “Sandy will use it this way.” While my design partner Lily and I are aware of the same five personas and understand their distinct perspectives and functional needs, we don’t know them. We never use their names in conversation. They aren’t real people to us because we never met them in real life. Liya and Arti did, and they can call on them for help just by uttering their names. Instead I find myself referring broadly to “the user,” and it’s becoming increasingly ineffective to do so — in particular because the product we’re working on has three very different user types.
So what’s the solution? Just as a person can wholly exist without being profiled (I wanted to say biographied, but I don’t think that’s a word), so can a user representative. If the entire team is involved in forming the personas, is it necessary to put them down on paper? Could there be another way of documenting them, such as video? Perhaps someone on the team adopts the persona and you take them out to lunch once a week? What other ways can we better synthesize user research and bring the valuable energy to the foreground?
Related Posts:
- Whit Hour – Week 10 July 6, 2010 | 0 comments
- Design — Architect — Engineer April 4, 2008 | 3 comments
- Personas in the 2008 Presidental Election November 2, 2008 | 5 comments
- Web 2.0 Expo NY: “10 Tips for Creative Environments” with Adaptive Path’s Bryan Mason and Sarah Nelson September 20, 2008 | 1 comments
- The Design Advisor: Why Every Startup Needs One March 20, 2013 | 4 comments
Right before I read your last paragraph, I was thinking that it would be great to actually have customers who have agreed to be repeatedly accessible to your design team. So, yeah, good idea!
Anyway, you raise a good question about personas: When the design team grows and new people are introduced, how do the designers who did the initial research communicate that experience to the new team members? The answer, I suppose, is that for a development cycle in which a product is under constant development, persona research should be conducted constantly as well.
All that being said, I think this is a slippery slope, too, transforming a concept for a useful but disposable design exercise (personas) into something that needs to replace or be an integral part of a formal research policy. I am skeptical of formalizing or fetishizing personas too much. I see them as an ad hoc exercise, akin to brainstorming, designed for rapid assimilation of user information with the goal of bridging the gap between data and design.
Perhaps the answer is that you, Whitney, should go over the data Liya and Arti had and make your own personas from scratch. Then compare the two sets. Should make for an interesting and enlightening — and, design-wise, inspiring — conversation.
When the design team grows and new people are introduced, how do the designers who did the initial research communicate that experience to the new team members? The answer, I suppose, is that for a development cycle in which a product is under constant development, persona research should be conducted constantly as well.