I think it’s important not to underplay a team’s made up personas (assuming they are including important aspects of the users – not fluff like the number of pets and favorite vacation spots). Not only do you risk throwing away useful information, but you risk alienating the teams you are helping.

I suspect most of these made up personas aren’t created completely in a vacuum and the team has some exposure to users, even if its second hand.

As a UX professional inheriting such personas, the first thing I would do is “validate” them internally and identify what was guesswork and what was based on fact. At that point, we’re back to “ad-hoc” or “provisional” again.

The goal remains the same. We need to expose (in a good way!) the organization to real users, whether through persona development, usability testing, or other methods within the given time and budget constraints.

Having an almost total-recall memory for faces, personalities, and people I meet in general has become an integral part of my UX tool-kit. While nothing can replace actual user-based research and Q&A, it is not always applicable for every given project/situation. I would never discount the intuitive ability required to craft a working persona out of thin air on the fly!

Our client wanted to scrap 90% of the site content on a large infrastructure site, and the personas (along with some simple scenarios outlining how users may have hypothetically used the popular content) helped to make them aware the importance of some content in specific contexts. It didn’t work in all cases, but it did prevent them from removing plenty of high-frequented and useful content. It certainly helped in encouraging the client to think more like their users, and step out of their corporate mindset.

We had a big internal debate about the usage of the term, “personas”. Our resolution was that it did need to be clear that they weren’t traditional personas, and I think we settled on calling them “fictional personas” at the time, although, I definitely prefer the term, “provisional personas” as I think it gives them slightly more credibility, whilst still distinguishing them from “traditional” personas.

“Assumptive” is an ugly-sounding, accusatory word which is kind of why I like it in this context.

Before I reveal the silhouettes, I give an example of a real persona and explain what it is and how its used.

The goal is to use assumption-based personas to introduce the business to the concept, and then to circle back and get them to do the real thing. I have one question about this tactic:

Has it ever worked for anyone?

I’ve been part of a number of these experiences and the ‘personas’ essentially wind up being stereotypes, often infused with the bias or agenda of a person or department.

These don’t really serve to reveal or guide the discussion or development of features but instead become weapons in debates and arguments. This ultimately devolves into people attacking the validity of the persona. From there, it’s a quick and slippery slope to writing off the personas entirely.

In my opinion, using personas (the right way) is a very difficult task and more people get it wrong than right.

As professionals that “get it” I think the best we can do is question and challenge when presented with personas to figure out how they came to be and then suggest the appropriate action to move them in the right direction.

Once the Persona Certification Organization (PCOrg – has a nice ring!) is up and running, we can standardize on names and labels. … and badges, of course!

One solution your your naming problem is to just call real personas “real personas” or “evidence-based” personas or something like that.

I have an additional gripe about personas. Sometimes, even when they are data-based, they don’t add much beyond knowing that some people are more technical than others. In my experience, useful personas include details about task patterns and context that can inform detailed design. It’s nice to know people’s backgrounds, preferences, and hobbies, but I also need to know what they do, how they do it, and why.