I'm studying HCI and the focus for persona creation on my course is resolutely that personas should be derived from user research data. I also attended adaptive path's uxintensive last year and the user research day was also in this camp. However recently I have had a few conversations with people who seem to suggest that its ok to 'make them up'.

Does anyone have any guidence as to when's best to go with whichever technique - or does it simply come down to budget and time constriants?


IMHO The bottom line is that all personas should be data driven, after all they are a tool to represent the user in the design/development process and as such they should be created with the attributes of the target user.

However, should all personas be created by "client specific" data? Pragmatically i don't think so. There is enough data around to support common personas for common products. Which can sometimes be enough, especially as UCD is still not pervasive in the design/development lifecycle.

For example: a pregnancy website would have several personas:

  • Expectant mother
  • new mother
  • etc.

I imagine there is enough data on the web which would allow for some convincing personas based upon relevant data.

Where you can go mad, is on the narrative. I love to embellish, to make them real. I use several images, imagine a family and tend to call them after people from my favourite TV show.



p.s. when creating personas please don't forget your anti-persona the person you are not creating the design for.

  • Anti-persona — that’s a really interesting concept that (I have to admit) is new to me. I’m going to think about using these on my current project.
    – Alastair J
    Oct 20 '09 at 12:43
  • Anti-personas are a great idea, and particularly helpful for sites where there are certain users you don't want the site to attract; that's a very important consideration for many social sites.
    – Ben Brocka
    Aug 10 '12 at 17:50

I think all personas should be data-driven.

If you insist on building personas based on your own feeling or guess ,be careful of 'the elastic user' trap.

Here is my favorite quotes about 'the elastic user' from ‘The Inmates Are Running the Asylum’ by Alan Cooper:

Whenever I hear the phrase "the user," it sounds to me like "the elastic user." The elastic user must bend and stretch and adapt to the needs of the moment. However, our goal is to design software that will bend and stretch and adapt to the user's needs. Programmers have written countless programs for this mythical elastic consumer, but he simply doesn't exist.

When the programmer finds it convenient to dump the user into the Windows file system to find the information she needs, he defines the elastic user as an accommodating, computer-literate power user. Other times, when the programmer finds it convenient to step the user through a difficult process with a mindless wizard, he defines the elastic user as an obliging, naïve, first-time user.

'Assumption' personas, the elastic user, simply give the designer/engineer license to do what he wants without user study, and creating the facade of user-centeredness.

Make sure your personas is based on real use research.

BTW, I think Steve Portigal has a strong opinion on this topic: no more personas.
Persona Non Grata


In my experience, 'assumption' personas rapidly fall into disuse because the development team don't believe in them. We have a checklist of 7 items that we check our personas against before submitting them to a client:

  1. Is the persona based on contextual interviews with real customers?
  2. Does the persona evoke empathy by including a name, a photograph and a product-relevant narrative?
  3. Does the persona appear realistic to people who deal with customers day-to-day?
  4. Is each persona unique, having little in common with other personas?
  5. Does the persona include product-relevant high-level goals and include a quotation stating the key goal?
  6. Is the number of personas small enough for the design team to remember the name of each one, with one of the personas identified as primary?
  7. Can the development team use the persona as a practical tool to make design decisions?

You may not find this method useful when you are in school, but once you are working, this can be a way to get some of what you need and an opportunity to educate about the value of user research.

When there is no research available, but you want to use "personas" as a method to help direct your design, I create what I call user "profiles".

Content is never made up, instead, it is derived from inputs from the business team (this could include someone from sales, customer service, call centre rep etc.).

It is made very clear to the business team/stakeholders that this is inferior to a true persona and that a persona is only ever based on user research. I also outline the risks and emphasize that the content is coming from their input, not from a fabrication by the design team.

This can often encourage the business team to allow you to validate the profiles with actual users to turn them in to personas. "Profiles" are also lower fidelity with less content because without input from actual users content would be limited. This can also help the business team to see where there are gaps in their knowledge about their users.

To do this, I conduct a workshop with the business team as a group. This is critical to bring about common awareness as to where they stand as a group in their knowledge.

Blank profiles are posted up on the wall (e.g. silhouette images, not faces/basic titles) the rest is blank.

Instructions, a sample and a walk through are provided as to what kind of information is expected and what kind of questions they should be asking themselves.

Everyone is provided with a set of sticky notes and a sharpie.

The group is split up into number of profiles.

Depending on the size of the group, they are given 4 - 10mins to write everything they know about a particular user and post it. Then each group rotates for another 4 - 10mins etc. until each group has had input on each profile.

Then the facilitator does a walk through of each profile to clarify any vague or confusing sticky notes.

The design team takes the inputs, does an affinity model (groups sticky notes by what they have in common) creates summaries of the content in the form of a simple persona (what I call a profile) that includes a one paragraph "story" and a user info "clouds" (think tag clouds, but for summary of user findings) e.g. "efficiency is key" "time-constrained" "brand driven" etc.

Then meet with the business team again and present the findings for further validation. This is the opportunity to demonstrate any gaps and encourage the business team to allow the design team to validate the information with end users.

Worst case, it provides the design team with some direction while providing insight to the business team as to why user research is critical.


Although I'm in agreement that data-driven personas are more reliable, there are situations when they can benefit from more subjective input.

For example, when your client has access to a bank of employees with day-to-day end user contact (such as call centre operatives). In this instance I think it's helpful to listen to the opinions of staff with this kind of end user knowledge, and it can be worth running "persona workshops" to get to the information.

  • I don't think anybody is arguing about having qualitative as well as quantitative data - but I've had quite a few instances where folk have obvious made things up from whole cloth. I find it fascinating when organisations spend time making up their perfect customer - not realising that they don't actually exist - and then act surprised when they don't get decent results :-)
    – adrianh
    Oct 16 '09 at 11:08

I recently viewed the UIE virtual seminar on Ad Hoc Personas by Tamara Adlin. Two types of persona were discussed with two very different purposes. (See http://www.uie.com/events/virtual_seminars/ad_hoc_personas/ - there's a preview video available.)

1) Data-driven personas are more of a product design tool and are based on actual user/usage data.

2) Ad Hoc personas are created using the information the organization already has at their fingertips. They are a communication tool for concepts and can help to keep a team or stakeholders focused. They can also be used as a preparation step (a testable hypothesis) for data-driven personas.

The fact is that most companies already have "personas" - ideas of who their user base is. Sometimes this is based on data and sometimes this is a corporate myth. Adlin says that "Hidden personas can wreak havoc on products" and I agree. So better to have a shared idea of personas.

The webinar was good and had some creative ideas for repurposing the persona technique and doing ad hoc personas really well. I'd recommend it for expanding your concept of personas.


I agree that it has to be based on research.

If you're interested in the topic, I'd suggest The User is always right from Steve Mulder and Ziv Yaar which is a very good book.

You can find it on Google Books or Amazon.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy