On Nov 27, 2007, at 9:50 PM, Robert Hoekman, Jr. wrote: > You do need something to document the activity, but I don't see how > a persona is the best way to do this.
Sigh. Once again, I'll try to be clear. *Personas* don't document anything. Personas are memes created by a team to help understand individual differences between user groups and how those individual differences can affect the final design. *Persona descriptions* outline a persona, but rarely do it justice, just like a description of your summer vacation probably doesn't relay how great it actually was. Just because the description misses the vitality of the actual event doesn't mean the vacation sucked. *Persona descriptions* are most useful with accompanying scenario descriptions, again based on research, to help the team understand the context of use that's dictated by individual differences. Creating documents are *never* the best way to do something. Using the document as a common stimuli to ensure the team is working with the same conceptual framework can help, when done well. When combined with discussion and other artifacts, documents can be very valuable. > I also believe that in a huge percentage of cases, you can learn > about the activity without locating and interviewing representative > users. Perhaps not in a hospital situation like the one you > mentioned, but in many other situations for sure. Sure. Never said that wasn't the case. A "huge percentage" doesn't imply a majority. If we're talking 20-40%, I'd be good with that. Beyond that, I'd like to see actual studies of cases, because, in our work with teams, I don't find that to be true. I'd like to know why your numbers are different. > And these cases are where my argument shows its benefits: you can > very often study the activity in half the time it takes to locate > and interview all those users. Maybe. Depending on the team's familiarity with the problem space, the time is going to vary widely. I don't buy this argument that resources are always shorter if you don't study individual differences between users but, instead, just focus on activity. > In your example, how different, exactly, is the process of ordering > a blood test going to be when you're a doctor as opposed to a > nurse? Assuming both have the authority to do so, the process would > be, well, identical, would it not? If the nurse doesn't have the > authority and needs a doctor's approval, then one step in the > process changes. The elements of the activity are pretty dern > stable compared to the roles the two personas play. In many private hospitals (which are the majority now, because of the privatization movement of the last 20 years), the process of ordering a blood test (say a CBC or a Chem-7) has become more complex due to billing and quality (aka avoiding-malpractice) issues. Nurses are typically trained to handle these cases, where doctors aren't. (Malpractice insurance for nurses is substantially cheaper than for doctors, being one factor.) In the rare instance where you'd have a doctor interact with a system for ordering bloods, it's likely that the user would be less aware of many of the prompts, constraints, contextual subtleties, and procedural details, thereby putting more burden on the system to check and enforce these issues. It's the equivalent to having a bank teller interact with the banking mainframe (the teller's workstation) versus having the customer directly interact with it (ATM). The activity is the same, but the context puts huge implications on the design. > I know I'm never going to "win" an argument like this with you, That's because I'm right! Mua ha ha ha! :D > so all this rhetoric is probably pointless. Yet, we persist. Pointless rhetoric is a theme on this list. (Hey, that would make a great band name: Pointless Rhetoric) > I'm just so tired of hearing about the "magic bullet" that is the > notion of personas when I have yet to find a company that uses > them, and yet to find a situation where I have been unable to > succeed without them. I never said they were any kind of magic bullet. I don't believe in magic bullets. I believe in hard work, skill, talent, and a bit of luck. All I said is that they are a useful tool for the designer's toolbox. And I've been trying to help clear up misconceptions about when they are useful. Part of what they are useful for is they reduce the role of luck and increasing the roles of hard work and skill. A team is fixed on the amount of talent they bring to the project. You can't add or detract from it without changing the team members. However, you can manipulate effort, skill, and luck. That's where something like a robust persona process comes in. > Heck - you could barely find a company that does them *well* (only > 5% you say?), so how can you be such an advocate for their use? Sturgeon's Revelation http://en.wikipedia.org/wiki/Sturgeon's_law When we start rating teams by the quality of the user experience they produce and we start comparing the methods the teams producing the best experiences use to the methods the other teams use, we see robust personas playing an important role. While most teams that claim they use personas basically do what people here have called "assumptive personas" or "ad-hoc personas" (hey, let's just write up a 2-page description of who we'd like our user to be), when we separate those out from the robust personas, you can see the difference in user experience quality. That's why we're strong advocates of robust personas. 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
