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.

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

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).

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

http://www.flickr.com/photos/brycej/2035000246/

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.

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.

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.

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.

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.

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.