Personas vs. User Descriptions; Apples vs. Tomatoes

Jared Spool

November 15th, 2007

The always intriguing Christopher Fahey commented on yesterday’s post about Crappy Personas vs. Robust Personas:

Personas provide a fabulous way for people who understand their audience/users to communicate their understanding to people who do not understand that audience in a rapid and meaningful way. They are also a great way for people who have different understandings of their target audience (users, customers, etc) to reach common ground on who they are designing for, particularly if the objective is to expand into new audiences rather than simply to serve an existing audience. Neither of these uses of personas requires any original actual hard field research to be done. All it takes is a few good conversations and collaborations around a white board, and a little running around to gather existing documentation.

In my mind, Christopher is clearly confusing Personas with User Descriptions. User descriptions are what-we-think-we-know-now writeups of who uses our design and why. Personas, on the other hand, are carefully researched and crafted personalities we create to focus the design energy.

I believe both are very useful in the design process. User descriptions help us see where our thinking is, help new team members come up to speed, and help us identify where we may have made assumptions that could turn out false. Personas helps us get past the this-design-is-for-every-breathing-being problem and help us focus our attention on the needs of three to seven specific individuals. Many teams regularly do both.

That said, I think confusing them would be a bad idea. It’s akin to using the term apple when talking about a tomato. They both are fruits, round, red, and have seeds in the middle. Yet, someone thinking they are getting an apple is going to be very disappointed on that first bite if they received a tomato instead (and vice versa).

A few years back, in a project studying the work of master wood craftsmen, we learned there are dozens of types of saws. All of them cut things (mostly wood, but not always). Interestingly, the best craftsmen knew the individual names of each type of saw they owned and were really miffed when you called a tool by the wrong name. To them, the subtle distinctions were very important, since knowing to use the right tool at the right time in the right way was a big part of what distinguished them from other, less capable, craftsmen.

So, I recommend we call things by their names and not try and bunch different types of design activities and deliverables under one name. (And don’t even get me started with the folks who often refer to usability tests as focus groups.)

16 Responses to “Personas vs. User Descriptions; Apples vs. Tomatoes”

  1. David Malouf Says:

    I think what many people forget about personae is that they are a modeling tool. Their primary purpose is to model research data in an approachable manner. Being a data model, they are meaningless unless based on research.

    The “feel good” consensus building stuff that people look to as the “excuse” for doing personae to me is a distraction of the real valuable message of personae as a tool that has its greatest value in moving a designer from research to actual design based on that research. In this way the designer is always held accountable to the research and must defend decisions that counter the models of that research.

    If all they were, were a feel good story, i could see why people wouldn’t want to use them, or worse, they want to use them, bu they don’t really hold true value to the design process; thus, backfiring.

  2. Christopher Fahey Says:

    I’ve never heard of “user descriptions” before, and I’m not the only one. This very post, which is only a few hours old, is the #1 hit on Google for the phrase “user descriptions”. So clearly it’s not quite an industry standard term! You can hardly call me “confused” over a term which, for all intents and purposes, you just today introduced to the world. 🙂

    I’ll admit, I spent some time last night trying to come up with a new and unique name for the kind of “knowledge-transference” personas I wrote about versus the kind of research-based “robust personas” you were describing. Don Norman already uses the term “ad hoc personas”, but to me that has a perjorative sense to it. It needs something more accurate, sure, but something that shows it to be a cousin of “robust personas”. Then you beat me to the punch with “user descriptions.”

    I’m not crazy about “user descriptions” though, if only because it sounds like a way of dumbing-down the Latin-tinged “personas” (like calling croissants “crescent rolls”). Why do you get to use the term “personas” while I have to think of some new term to talk about my approach? It’s not like personas have always been of the “robust” variety — as you yourself have said, the “robust” kind is far and away the exception to how personas are actually practiced in the wild.

    But hey, I don’t want to get in a dispute over terminology. I think we both fundamentally agree that we need to call these two animals by different names, and the profession needs to stop arguing that “my way is right” when there is room for many different approaches. I’ve never been an advocate for standardization of any professional design practice, but I agree that it would help to remove this particular ambiguity from our domain.

    And thanks for calling me “intriguing”! 🙂 Needless to say, right back atcha.

  3. Derek Featherstone Says:

    An interesting series of posts in a short time. I agree with what you’re saying, Jared, but wonder if calling a “user description” by that name reduces their value as we work with clients? Would it be better to simply distinguish user descriptions from personas by qualifying them a bit? “Research-based personas” vs “Descriptive Personas” maybe?

    I only bring this up because we have clients that already speak the language of “personas” (be they crappy or not). After reading several posts this morning, I suspect they are descriptive personas and not research-based. It would be much easier for me to talk with them in their existing language, knowing that they already call what they have personas, and to extend that to make the distinction between research-based and descriptive ones.

  4. Christopher Fahey Says:

    @Derek: I like “descriptive personas”. But as per my last comment on the last post, I don’t think that “descriptive personas” are necessarily devoid of research. Plenty of research can and should inform the creation of “descriptive personas”. It’s just that the research may not have been done explicitly for the purpose of generating personas. The research may take the form of reading existing documents and records and collecting knowledge from the brains of very smart people in the organization.

  5. David Geerts Says:

    Isn’t this what Pruitt and Adlin call “Assumption Personas”? A Google search on “assumption personas” returns 54 hits, so at least that part is already covered. Although they should be used with care, they make the assumptions of everyone in the team explicit. The book by Pruitt and Adlin (The Persona Lifecycle) is a very good primer on how to use personas in practice, and covers a lot that is being discussed here and elsewhere recently.

  6. David Geerts Says:

    Isn’t this what Pruitt and Adlin call “Assumption Personas”? A Google search on “assumption personas” returns 54 hits, so at least that part is already covered. Although they should be used with care, they make the assumptions of everyone in the team explicit. The book by Pruitt and Adlin (The Persona Lifecycle) is a very good primer on how to use personas in practice, and covers a lot that is being discussed here and elsewhere recently.

  7. Keith Says:

    I’ve never heard of “user descriptions” before. Therefore this seems like nothing more than a semantic debate. Albeit one that brings up some interesting thoughts about personas in general.

    I think I agree with David Malouf up there.

    To me “user descriptions” just sounds like personas that aren’t using actual data. Which, in my opinion anyway, might be a waste of time. I see personas as a very tricky deliverable, even if they are chock full of great data and observations about users. They’re fuzzy at best, providing little value beyond documenting data found in research, which often is ignored by designers and developers. And often for good reason as what is contained in a persona doesn’t always translate well to design decisions, let alone anything a developer can use.

    They’re also tricky to craft, especially if your crafting them for someone else. It seems like we end up spending as much time haggling over the fiction as we do doing the research. Clearly not a good use of time or money. I’m not saying they don’t have good use – only that you have to be careful lest you put more effort into them than their worth.

    Their best use, in my opinion, is that they give you an excuse to go out and spend time with users. That experience you gain from observing is much more valuable than any persona (or any other research document) I’ve ever used or created. As well, they give a frame of reference for speaking with your stakeholders about users, always a good thing.

    Still, our clients do ask for them. We always argue that they’re only valuable if based on research and we always call them “personas.” Seems to be working just fine. I, for one, would just as soon avoid the semantic debate. And expressly or that reason I’m *not* showing Nick (Finck) this post. 🙂

  8. Benjamin Ho Says:

    Personas, User Profiles, User Descriptions, they all do one thing – tell us something about the user from which to work upon, whether it be factual or by proxy. While I like the idea of “standardization” so that there’s no disparity in our terminology and definitions, this “over anal-yzing” can sometimes be counter-productive (and a bit annoying). Perhaps then there must be a Usability Dictionary so that we can all agree on terminology as well as certain methods used due to certain circumstances.

    What I do know is that in a certification course (i.e. HFI’s) the language and terminology spoken is clarified in reading material so that there’s no ambiguity. I think that’s what most of us in this profession hates the most – ambiguity.

  9. Keith Says:

    @Benjamin Ho – Are we all really that ridged in our thinking that we need to agree upon terms for this stuff? I certainly don’t think so. I agree that we often spend way too much time haggling over this stuff, but to me the answer isn’t to come up with common terms that everyone should use (which won’t work anyway and is a waste of time.) No I look at the terms you’ve listed above and feel like that with a small amount of clarification from the person using those terms I could easily suss out the differences in them if any.

    My general rule is I use whatever terms my clients use. And trust me, there are many times I initially have to have them explain what they’re referring to as their terminology is often far different from my own. I’ve very rarely had problems with this, and it’s because I simply choose not to get caught up in it. Now, if someone doesn’t have clients, they might have the luxury of nailing down very precise terms for the work they do and the deliverables the create. And that’s great. For me a bit of ambiguity is preferable to endless semantic debates.

  10. Bryce Johnson Says:

    I agree with Kieth as someone who believes in speaking with the voice of my customer I use whatever terms my clients feel comfortable with. Wireframes are sometime strawmen, User Roles are sometime Actors, and if I have a two hour meeting in project to create “personas” then that is what they get.

    I like the idea that sometimes personas are crappy and sometimes the project restrictions dictate that you can’t do what you would normally do over coming up with new work products that is just confusing people outside our field.

    I worked on a project where after doing some field research with 10 people from 5 business units my client asked me to do a set of “personas” specifically around aspects of how people accessed information on their enterprise. Now I don’t think these are personas but I do think that they were incredibly useful and I had less then an hour to create them for a presentation we were giving to the project stakeholders. These are research based “personas” that are crappy and useful 🙂

  11. links for 2007-11-16 : Alistair Brown - Digital Media, Publishing, Newspapers Archive, Archives, Digitisation Says:

    […] Personas vs. User Descriptions; Apples vs. Tomatoes » UIE Brain Sparks (tags: personas usability design toread) […]

  12. Zef Says:

    Hi Jared – you’ve made some good points – this is something I’ve been acutely aware of as well…

    Our user research process at Provoke starts by creating a ‘persona hypothesis’ – this is usually done in a workshop with the client, and where possible we involve people who have had actual contact with users. This would be your equivalent of a ‘user description’. For about 50% of projects this is all we have time/budget for, but I still think this is better than having no idea of the users.

    If time/budget allows the next stage is to go out and validate the hypothesis with quantitative (stats analysis/surveys) and qualitative research (interviews/observations). We then update the persona and a lot more detail is added. Sometimes the process means we uncover whole new personas. Sometimes we discover people the client assumed were users (e.g. visitors to their website), are in fact not users at all! (they don’t go there, or very rarely).

  13. Harry Brignull Says:

    I like the distinction that Jared is making, and everything else he’s saying here, but I’m not so sold on the terminology. “User descriptions” – the term doesn’t explicitly say “The kind that’s based on assumption, not research”.

    “Assumption Persona” seems to hit the nail on the head. (Good point David).

  14. Christopher Fahey Says:

    How about, then, “Hypothetical Personas”?

    Putting on my salesperson hat, I can say that such a name would be a great tool for upselling the subseqent “validation” work, if only to remove that nagging “Hypothetical” from the documents.

  15. Personas: Gode råd & meninger » More discussions on personas have been published recently Says:

    […] Personas vs. User Descriptions; Apples vs. Tomatoes Jared Spool […]

  16. adaptive path » blog » Todd Wilkens » Avoiding Half-baked Personas Says:

    […] Typically, they are based mostly on intuition and unconnected bits of market research. (Hence, Jared Spool doesn’t even want to call them “personas” but just “user descrip…) These kinds of descriptions can be helpful, especially in a better-than-nothing situation or as […]

Add a Comment