24 thoughts on “Creating personas for information-rich websites

  1. Yes, I did make an effort to use the statistical technique (Factor ANalysis) to do what Cooper recommends as a way for designing personas: i.e., identify patterns of needs or goals. But it is possible to get different types of personas by doing some things differently with the Factor Analysis. I should try a few more types of analysis.

  2. The personas created seem pretty similar to those that one would get from a Cooper type method. Is that deliberate?

  3. Rashmi,

    I have seen no evidence that you can derive “accurate” personas from quantitative methods, as you are trying to do. However, your efforts will serve as a fine proof of my assertion that specificity is more important than accuracy. Although your quantitatively-derived personas will assuredly be inaccurate, as you will find, they will still work as an adequate design tool. All that remains is the actual effort of design, which, sadly, personas cannot do for you.

    PS. Why not come take one of our Cooper U classes and learn how to do it the right way?

  4. In information-rich applications, understanding the way the user’s mental model of the information space could come in handy during the design phase.
    However, the technique seemed to surface use cases for the application, not personas. Or more specifically, use cases for restaurants (“romantic date” use case, “getting the kids fed” use case). Still pretty important to know if you’re building a restaurant finder.

  5. Quoting Alan Cooper:
    “I have seen no evidence that you can derive “accurate” personas from quantitative methods, as you are trying to do.”

    How? Could you be more specific? I am not quite sure why you see the process I have described as not producing “accurate” personas. A comment like: “Not necessary” I would consider a matter of personal opnion. But how is it not producing accurate “personas”. Appreciate your feedback.

    Thanks for stopping by!

  6. I think it is inappropriate for you to take my comments out of context. I think you destroyed my meaning by editing them.

  7. Rashmi,

    As we say on the east coast, this is WICKED COOL! I think that the method is right on and has real advantages.

    I’ve often been very concerned about the use of archetypal characterizations for persona development. I’ve been very concerned about inter-creator reliability (the same issue — do multiple persona creators create the same persona from the same data?). I’ve also wondered why, when there are so many *real* people on the planet, we have to spend precious development time creating imaginary ones. (However, creating new ones — people, not personas — is something I heartily recommend, with moderation. Plus, practicing is fun.)

    Coincidentally, our research has taken us on a similar path. We’ve been looking at combinations of survey results and shopping behavior to cluster people into groups (using a principal components analysis) that look and feel like the demographic distinctions often used for marketing purposes. (To find out more about this, you really wanna talk to our First Science Officer, Will Schroeder (wills@uie.com) to learn how we’ve done it.)

    The cool thing about this is that we can, for an e-commerce site, validate if marketing’s existing demographic groups are important (Do different groups behave differently and need different designs?) and are there alternative groupings that are more important. It’s the next logical step to take these groupings and create or assign personas.

    In the Cooper universe, you *create* the persona and describe him/her. In my universe, you find someone who is pretty much the living persona, *assign* them the role of being the persona, and then describe him/her. The advantage to my approach is that you can ask him/her questions (like do they prefer to called ‘him’ or ‘her’).

    At the risk of putting words in Alan’s mouth, I’d say that the Cooper argument has been that archetypal characters allow for (1) the combination of features not easily found in individual real people and (2) gets the creative juices of the team focused on something that will have positive affects. (They’ve got other reasons too, but these are the two that stand out in my mind.)

    Whether you adopt archetypal characters or assign persona roles to real individuals, you still need a way to know if you’ve done the right thing — if you’ve got the right persona. And that’s why this is WICKED COOL!

    Alan,

    Don’t get your buns in a knot! (What does that phrase actually mean? I don’t really know.)

    Research like this is exactly what needs to be done. Nobody is going to dethrone you as King of Personas by do this type of work.

    Seriously, you know that I think that Personas are absolutely critical to the design process and I think the world of your techniques. And I am not alone in this.

    However, the costs of developing solutions for the wrong persona, as Rashmi rightly points out, are too high and create huge risk for the team and the future of the process. Your team and the people who you’ve directly train are probably less at risk than the myriads of folks who are trying the technique out untrained.

    We need research like this to help us understand how we validate and improve the techniques, allowing more people to be successful with them, which meets everyone’s goal of a world with better, less frustrating, more usable technology.

    Jared

  8. This is very interesting work–it opens the possibility that some limited tools may be available to allow shoestring projects to develop at least minimal personae. The vast majority of the UIs I design simply don’t have the budget to do more than “guess right”… unless I can put a tight box around the analysis I would have to do to develop a few (or even one) key personas.

    I’m terribly interested in the factor you dropped; it seems to me that there’s bound to be something there!

  9. The fourth factor that I dropped seemed kind of vague. Seemed to comprise medium ratings on pretty much all features. Could not find a clear pattern there. I should note that I did this analysis with 38 users, and now have data for about 15 people more. I might find clearer patterns for the fourth factor when I redo the analysis.

  10. Rashmi,

    Any good methodology is always evolving, so the way we create personas is always open to improvement.

    However, there seem to be misconceptions about just what personas are and how we create them at Cooper. They are behavioral models (not fictitious biographies) based on user observation and interviews. There IS, in fact, a very tight coupling between the two, since individual user data is mapped against a set of behavioral variables to show patterns. Each major behavioral pattern becomes a persona. All of the information in a persona description (aside from the name and a couple of persnal details) is drawn directly from user data. Given the same data set, any competent practitioner trained in the method WILL come up with essentially the same set of personas. This degree of rigor may not be evident in our one-hour lectures or even one-day overview classes, but we do share it in our 5-day classes.

    I would also like to emphasize that there is no substitute for direct user observation, since it’s well-understood that self-reported behavior is often inaccurate. Also, many of the most important clues to problems and opportunities can be found only in the user’s environment. By combining observation with interviewing, we can get a range of behavioral data in a short period of time.

    Also, we never ask users what features they want–that’s how you get products like the Edsel, a notorious failure of an automobile. Users are experts on their own pain, but generally not on how best to cure the disease–this is especially true when we are inventing new products unlike any the users have seen. By understanding frustrations, mental models, and goals, we can come up with functionality the users themselves would never dream of, but love once they use it. That’s the power of using goals, rather than just looking at tasks or feature preferences.

    I would hate to see anyone scared away from creating personas because they think it’s expensive and time-consuming. You can create a solid persona set with 3-4 days of research for most consumer products, perhaps up to two weeks for very complex business products. We DO occasionally create what we call “provisional personas” with little or no research, but that’s only when the product is shipping in a couple of weeks–those provisional models are not as useful as real personas, but are still a convenient shorthand to use in quick and dirty design meetings.

    Finally, regarding the “precision vs. accuracy” issue, the statment has been misinterpreted. The point is that it’s critical to understand your users’ behavior with great precision, since interaction design also involves great precision. Good research techniques should lead to accurate personas, though of course we would love to do broad quantitative research with appropriate rigor to ensure the accuracy of our qualitative work. Unfortunately, few companies have the time or budget for this.

    Best of luck, and please contact me for any clarification about personas.

    Kim Goodwin, Director of Design, Cooper

  11. Thank you for your feedback Kim. And everyone else who chimed in. I have gained some valuable input and will be sure to incorporate your suggestions and criticisms as I work more on the project.

  12. Cooper’s done a great job of promoting personas and putting his own twist on them, but they have been used for well over a decade. I suggest you don’t forget to look beyond the most popularized approaches:

    Jonathan Grudin is studying their use and already has one paper available: http://www.research.microsoft.com/research/coet/Grudin/Personas.pdf

    John Carroll (http://people.cs.vt.edu/%7Ecarroll/) has written numerous works on scenario-based design (from which personas was obviously derived). His latest books are Usability Engineering: Scenario-Based Development of Human Computer Interaction, by Rosson and Carroll (2001) and Making Use : Scenario-Based Design of Human-Computer Interactions (2000).

  13. Cooper’s done a great job of promoting personas and putting his own twist on them, but they have been used for well over a decade. I suggest you don’t forget to look beyond the most popularized approaches:

    Jonathan Grudin is studying their use and already has one paper available: http://www.research.microsoft.com/research/coet/Grudin/Personas.pdf

    John Carroll (http://people.cs.vt.edu/%7Ecarroll/) has written numerous works on scenario-based design (from which personas was obviously derived). His latest books are Usability Engineering: Scenario-Based Development of Human Computer Interaction, by Rosson and Carroll (2001) and Making Use : Scenario-Based Design of Human-Computer Interactions (2000).

  14. I am familiar with Caroll’s work and have been reading his “Making Use” book. Good to know about Grudin’s work.

    Yes, the concept of personas and scenario is not new. And I have been actively looking for references to older work.

  15. From what I read you are looking for representative users. But from my work on my book with some persona experts including former cooperistas, it is not the representative user you want to design for, but the needy one. The one that provides the design challenge, that– by solving– you will provide for less needy folks.

    The classic example is the stewardess and the rolling case. Stewardesses were often small women, traveling all over the place, never knowing where they are going next, possibility of luggage loss– they had a set of highly specific and distinct needs. Voila, the rolling case was born and is now carried by millions of travellers. I think while statistically defining the representative user might be useful for developing a persona used for evaluation through cognitive walkthroughs, I don’t think that persona would be equally useful for designing a system.

    Cooper used to have a case study on their site that i can’t find now, that showed off the design of a inflight entertainment system. While the typical flyer could use a complicated navigation system, they chose (if memeory serves me right) an older gentleman who wasn’t tech-savvy and a child as personas, leading to the design of a very simple system with a navigation tool that was easy to use for someone with low manual dexterity. This system could be used by the typical and the challenged user. Thus the design met more users’ needs.

  16. Good point about the stewardess example CHristina. A slight clarification though: this method does not identify clusters of users, or “representative” users. It identifies “clusters of needs”. That is a subtle but crucial difference (I tried both, and this gives a lot more useful answers). So no one person might represent the cluster of needs that you find.

    Secondly I think information rich domains are different than the examples you offered. One needs to understand types of user needs, and mental models, not just the “needy” user.

    Also I think of this technique as another alternative in the toolkit of designers rather than a replacement. For certain design problems this might be more appropriate, for others it might not be.

    Finally regarding the goal for this: Think of the way designers use card sorting to understand user mental models in a quick and dirty fashion. Well if you trace card sorting back to its academic roots, its a long ponderous technique (like most academic techniques). But designers have adapted it their own needs in a very cool way. My goal is similar: to reduce this method its essence into something that can be carried out by every designer who wants a quick way to understand their users better. Currently this write-up just describes the jist of the idea. Its not there yet (by far), but I am working on it :-)

    I notice your book is out. Congratulations! When is the book launch party? Or did I miss it.

  17. all good points, rashmi– I’ve long wondered about the best ways to apply personas to IA. There do seem to be marked differences in approachign IA than ID in my experience.

    As for the book party, i havent’ figured out the where and when… working too much I guess. But soon, and I’ll annouce on ye old blog,…

  18. This strikes me as an issue of different tools for different situations…

    Rashmi does highlight one issue that’s been nagging me for a while — validing that you’ve got the right personas and scenarios. With software-ish sorts of things this has always seemed easier for me, for a couple reasons. Usually it’s been automating an existing task, so while you may end up doing some process re-engineering, you’re starting with a group of known users, as well as tasks you can analyze. (I haven’t done general audience software products, so I realize it may be a harder to nail down in that situation.) With the content-oriented web sites, I’ve worked on, it seems like identifying the users and scenarios was more difficult, but again this could be due to the projects, which were sites with broader audiences — and these sites arguably did a poor job in developing a marketing focus that would’ve targeted particular users.

    In general, I think I’ve done a good job of getting it right by intuition — and arguably that’s part of the skills expected of good UX practitioners. But while I think survey research shouldn’t be required to develop personas and scenarios, I think it’s potentially quite useful in validating them (assuming the client is willing to spend the time and money, and depending on the amount risk involved in the development costs). I’ve run across some interesting techniques in Sheila Mello’s “Customer-Centric Product Definition” http://www.amazon.com/exec/obidos/ASIN/0814406688/interactionby-20/002-7723352-5434432 which comes from the traditional product development field. (In her field, I think it makes sense given the high risks involved: the tooling of manufacturing plants, the costs of a flopped products stemming from wasted marketing and distribution efforts, unsold inventory, etc.)

    She uses similar methods to UX research (task analysis, observation, etc.) to develop the equivalent of personas and scenarios. But what’s interesting to me is that once you’ve identified a number of the key task/goal scenarios, she then uses a survey to check both prioritization of which things people feel are important, as well as a Kano survey (which asks about the satisfaction/dissatisfaction related to whether the purposed product would/wouldn’t enable the user to accomplish a particular task/goal. If I remember one her examples from designing a golf club bag, the Kano question pairs look something like: How would you feel if the bag helped you find the club quickly? How would you feel if the bag didn’t help you find the club quickly. (The idea is that some things people won’t give you credit if it’s implemented but will be upset if it’s not there, and others that they won’t feel deprived is it’s missing, but will be happy if it’s there.) It’s important to point out Mello is testing scenarios and not features.

    Mello argues that advantage of surveying is that you check your ideas against a wider against, which guards against your ideas having been skewed by the small sample size that’s inherent with qualitative methods. My take, is that it’s also got the advantage of coming up with some numbers to keep quantitative types (i.e. most business execs) happy.

    Given that online survey’s are relatively easy to set up these days, I think it’s worth being open to seeing how quantative techniques can complement our intuitive/qualitative ones. Of course there’s still the time and expensive of recruiting survey subjects, but the methods Mello describes seem like developing the survey questions can be done quickly, since they’re based around the scenarios already developed. And if you’ve got an online survey, you can capture the responses directly to a database, which eliminates much of the grunt work of compiling things (of course you’ve still got to do the analysis, but Mello’s analysis are pretty straight-forward).

    Finally, just to point out the obvious, like any other testing, it needs to be balanced against the designers judgement, since part of their skill should be seeing solutions the users may not see.

  19. Regarding Christina’s ponderings about how to best apply personas to IA (vs. ID). One problem I’ve with personas is they often lack enough “tactical” information that’s needed when you get down to actually designing the IA (and the UI).

    I’ve been working on adapting a nice list that Larry Constantine and Lucy Lockwood talked about in “Software for Use” http://www.amazon.com/exec/obidos/ASIN/0201924781/interactionby-20/002-7723352-5434432

    The checklist focused characteristics of the interaction (frequency, continuity, intensity, etc.) as well as of the information involved (flow direction (to/from user), volume, complexity, etc.) as well as some other factors.

    Since Larry’s a software guy, it’s oriented towards ID, but I bet the librarians in the crowd could help come up with a list of “tactical” information characteristics that would be useful for personas on IA-focused projects.

  20. George, the Mello link seems very interesting. Thanks. I have not read the book, but I she uses surveys probably for the same reason that you mentioned (they are easy to set up and run). And they really truly are easy. Once you have designed one or two, you can just take previous efforts as a template and devlop a new one in 1-2 hours.

    What Mello suggests in terms of verifying results of qualitative technuques makes sense as well, but I am using survey in a slightly different way (for exploration rather than verification).

    Let me explain: The fact that I am using exploratory statistics is more important than the fact that I am using a survey. Exploratory statistics is most similar to visualization techniques. Allows you take a chunk of data and see patterns. A low-cost way of identifying if there are patterns that fall out your analysis. (Also I think that exploratory statistics are far more interesting to UCD than “inferential statistics” (means, t-tests etc.) which are more commonly used. Exploratory statistics make suggestions rather than lay down laws. Unfortuantely they are rarely used in UCD. Card sorting with cluster analysis is probably the best example of the power of exploratory statistics.

    Having said that I do think Mello’w use of surveys for verification is equally valid and possible in UCD as well. The survey would need to be slightly differently designed. Let me get hold of that book before I make more comments.

    Also I am in complete with your below statement: Finally, just to point out the obvious, like any other testing, it needs to be balanced against the designers judgement…

    The persona creation technique I describe only suggests a few groupings of user needs. How the designed uses that information to form the personas is entirely up to them. An example: In the writeup I describe three personas. Actually the analysis gave me four user need groupings. I exercised my judgment as a designer to decide that only three of the groupings were useful to me. Thats the beauty of exploratory statistics, it shows you patterns. Rest is upto you.

    I should shut about exploratory statistics before I put everyone to sleep, and also show myself as a total geek :-)

  21. Glad you found my references useful, Rashmi. FYI, Kano himself suggested adding a sixth option “N/A” to avoid getting invalid responses if people think the issue is irrelevant (as opposed to being indifferent about it).

    As far as exploratory statistics, I think your methods are converging with traditional marketing techniques — although all too often marketing research focus on features, done right it first focuses on consumer needs. You might be interested in “Counterintuitive Marketing” by Kevin Clancy and Peter Krieg http://www.amazon.com/exec/obidos/ASIN/0684855550/interactionby-20/002-7723352-5434432 which discusses this sort of research at length — and also offers a sharp critique of what’s wrong with a most current marketing departments. Of course, they’re hard-core quantative guys, so their solution to everything requires six months and six figures worth of research, so I’m not convinced their solutions are entirely viable either.

    Interestingly, one of my marketing books — it may be Counterintuitive Marketing — essentially duplicates the concept of personas (they’ve got a nice term for it: “indi _visuallizing_ your customers), which they use to put a human face onto a mound of demographic data. As far as I can tell, they seemed to have evolved this indepedently of any knowledge of personas in the UI world. My best guess is it developed out what’s called “account planning” in the advertising world, which has techniques that are often similar to “our” user research.

    (It’s really interesting to see the convergences among different fields. For example, I first ran across Kano questions as part of James and Suzanne Robertson’s excellent Volere specifications template http://www.systemsguild.com/GuildSite/Robs/Template.html in the software engineering field — although they didn’t appear to know about Kano, since they didn’t suggest doing any of the analysis that’s part of Kano. The Robertson’s requirements development method, build upon on Gerald Weinberg’s excellent work, is heavy on understanding users — albeit from a traditional IT perspective.)

    Anyway, it makes sense for us to ally ourselves with others, such as marketing, when it makes sense and particularly when we can piggyback on some the work they’re already doing. The biggest difference is one of focus. Marketing is focused on getting people to a “buy decision.” I like to think that we’re focused on getting people to a “buy again decision” — that’s to say they’re so satisified with the site/software/product that they want to use it and buy it again.

    Obviously doing more quantative research adds time and cost to the development process — and can easily be misused and abused — so in large part I see the need to do this (as well as prototyping, testing, etc.) as related to the risk involved. The bigger the risk, the more you probably want to consider using methods that research/validate against a wider pool, assuming of course you’ve got time and money to do so.

Comments are closed.