[Note, I've combined comments from Andrei, Robert, and Jeff into one message so I don't fill up everyone's mailbox.]
On Nov 16, 2007, at 5:47 PM, Andrei Herasimchuk wrote: > On Nov 16, 2007, at 2:13 PM, Jared M. Spool wrote: > >> First, personas *are* already successful. Many teams are using them >> and getting great value out of them. They are not in general use, >> but they are being applied in many applications and seeing much >> success, by many different metrics. > > Many teams versus a well established, industry standard practice are > different things in my opinion. I think there's a quite a large chasm > between the two right now when there probably shouldn't be. With that criteria, why are you picking on personas? Practically every modern design technique falls into this distinction, including user-centered design and agile methods. There are no 'industry- standard practices', short of build-it-and-ship-it. In our research, we look at organizations who are trying to produce great user experiences. We rate the projects on a scale representing who is doing better at this goal than others. Then we look to the techniques and practices they employ. What we've found is, while 'personas' are used throughout the entire spectrum, what we call 'robust personas' are typical in projects on the higher end of our success scale. These teams are using these techniques to inform their design process and producing great designs as a result. On Nov 16, 2007, at 6:04 PM, Robert Barlow-Busch wrote: > In the end, personas are just a report format. Or if you hate > reports (and > who doesn't?), think of them as a communications channel. > > I cringe when people talk about needing personas. No you don't! You > need the > particular *insights* communicated by personas, insights about goals, > behaviors, and context. If you don't need those insights (perhaps > because > you're the customer and can design for yourself), then forget > personas. Robert is correct in that it's mostly about insights. But the insights aren't delivered by the persona description document. The insights come from the process in its entirety. (As an aside, in our work, we think personas are more than for insights, because the team may need them just to confirm hunches and beliefs they already have. If the team designs a quality experience without gaining new insights from the persona creation process, we still consider it successful.) I disagree with Robert's assertion that personas are "just a report format." Robust personas are a technique for getting the team on the same page about who their designing for and the goals, behaviors, and contexts they need to consider to create a successful experience. Like any design research technique, it's inevitably about informing the design process. Yet, we've found many teams, like Robert, believe personas *are* just a report format. Teams that believe this, in our research, rarely succeed at designing great experiences for their users. (Similarly, they often believe requirements documents, market statements, and other written deliverables are just report formats too and fail to get the potential value from those deliverables too.) This is why I think looking at the final persona description document doesn't tell the entire story. It's a design souvenir that represents, in the mind of the team, the journey they've been on. You can't judge the magnificence of the Eiffel Tower from a postcard. On Nov 17, 2007, at 5:40 AM, Jeff Patton wrote: > Jared wrote: >> In every description I've ever read of creating personas (yours, >> Cooper's, Pruitt & Adlin's, Gomoll & Story's, and Mulder's are the >> first to come to mind), they all go into great depth about the data >> collection and synthesis methods. I've never seen a persona creation >> description that just said, "It's ok to just write up what you think >> your users are like based on your experience and gut feel." (Andrea >> Wiggins' latest Boxes and Arrows article [http://tinyurl.com/33hrta] >> comes close, but claims to be data backed under the guise that >> analytics are useful data points.) > > What about Norman's article: http://www.jnd.org/dn.mss/ > personas_empath.html > where he writes: > "As a consultant to companies, I often find myself having to make > my points > quickly -- quite often in only a few hours. This short duration > makes it > impossible to have any serious attempt to gather data or use real > observations. Instead, I have found that people can often mine > their own > extensive experiences to create effective Personas that bring home > design > points strongly and effectively." Don's not really describing the process of creating anything, short of a set of notes from interviewing the team. You can put Cool Whip and Hershey's Chocolate Syrup between three slices of Wonder Bread and call it a 'cake', but that doesn't make it a cake. And to people who take pride in baking cakes, insisting that any combination of sugar and wheat is some sort of cake marginalizes the efforts they make. People say, "I've had cakes and, frankly, I'm not impressed with the results," when they really haven't experienced a quality cake -- they've just eaten a pile of crap ingredients that weren't even baked. If Don wants to interview the team, discover what they believe about their users, write them up, and call them "a persona" to make the client think they are getting something special, I'm all for it. They are his clients and he can have any relationship he wants with them. However, I suggest, amongst ourselves, we refer to these things by their proper names. Once again, I'm not saying that Don's process is without value or merit. I'm just saying it's not a 'persona' as I've come to use the term to describe a specific process. Instead of giving them their own name (like 'user descriptions' or something equivalent), some are suggesting adding a modifier to qualify the quality of the persona ('assumption-based personas'). To me, that's like calling the concoction I described above a '3-Layer Whip Cream Bread Cake'. I've come to think of persona creation as a process involving primary research, not the propagation of uninformed assumptions and marketing propaganda. I don't see how, as a field, we benefit by diluting the term by making it inclusive of all these variations. On Nov 16, 2007, at 5:47 PM, Andrei Herasimchuk wrote: > I've seen > many poorly written and poorly designed persona deliverables and > processes that provide very little utility to designers. I'm speaking > from my personal experience, and in case I wasn't being clear enough, > I'm all for a persona process that works. I have yet to experience > that myself, but I'm not the enemy here. Ok. That's fine. We can be in agreement here: poorly-done personas don't add much to the process and eat up a lot of otherwise useful resources. We recommend to our clients avoid investing in poorly-done personas. If they can make the investment (and it's not a huge one), we recommend a robust persona creation technique. If they can't afford that investment, we recommend other techniques. Someday, I hope you have the opportunity to work on a project that employs robust personas. I'm betting you'll see their utility at that point. If I'm wrong, then I look forward to learning from your story of your experiences. Jared Jared M. Spool User Interface Engineering 510 Turnpike St., Suite 102, North Andover, MA 01845 e: [EMAIL PROTECTED] p: +1 978 327 5561 http://uie.com Blog: http://uie.com/brainsparks ________________________________________________________________ *Come to IxDA Interaction08 | Savannah* February 8-10, 2008 in Savannah, GA, USA Register today: http://interaction08.ixda.org/ ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... [EMAIL PROTECTED] Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help
