7

I am currently putting together some personas and am creating a template that will be informed by user research. What I'm attempting to do is avoid the classic 'assumptive' persona and avoid adding made up stuff. For example I don't want a fake name but will call my first user type 'Student'. I'm not using a fake portrait but use an icon or illustration.

The question is, has anyone done this or seen examples of truthful, non asumptive personas?

I essentially want a persona which people can use and not have to guess what has been filtered out or made up. Suggestions?

1

8 Answers 8

6

I typically find most persona templates unhelpful when faced with the actual design "this is jan she's this role and likes to do xyz" which of course is I guess great for a framing effect but realistically it adds no value to the design when it comes to understanding LIKELY or ACTUAL behaviour (ie behaviour science and all).

I also am less at times interested in what the user is doing TODAY but more focused on what I need them to be doing Tomorrow. Analysing TODAY simply lets me know what habits have been formed, what behaviour patterns exist and thus I can use as a baseline for measuring migration patterns for TOMORROW.

Instead I opt for a card approach that centres around these options

  • Influence (low to very high). Take training, mentoring, buying power, optimization etc. as categories you can help shape the low to very high score. Basically how much influence does this persona have over the adoption of your new product, the training burden required in order to use your new product and lastly the output of the product (i.e. are they the end customer for your customers customer).
  • Usage (low to high). Similar to influence but now how much of the actual product are they going to be using? Specifically which modes of the product are they using (e.g. Visual Studio – Build time, Debug & Runtime). If you are writing software for both an executive assistant and their boss, then basically it is likely the assistant is going to have a higher rating then the boss depending on the scenario (vice versa).
  • Form Factor. What are they using to access the product? Given tablets, smartphones, laptops etc. are all evolving technology what is the likely input of choice. Do not just isolate this to device/platforms but also are they using stylus pens, are they using modified keyboards etc.
  • Environment. What is type of environment are they using the product in? Is it inside a coal mine where it is dark (i.e. white vs. black colors are a safety issue), is there many hazardous issues nearby? Is it noisy (distraction and cannot hear sounds), is it inside an office? Is it inside an operator building where your product is one of sixteen screens? Environment is really an important amount of information that gets lost in the “Story” creation. As we really need to pay attention to how much duress, the user is under in order to make their life simpler.

Basically Age ranges etc aren't as useful in most software team(s) design/development situations. Given the evolution of a demographic of users the whole age barrier is becoming less relevant and we now know more about human behaviour than we did 5-10yrs ago when that was of relevance. For instance we know humans have pattern recognition and there are a series of patterns that we can tap into. We also know that a human will not exclusively use your "design" only, they aren't virgins and have been using a plethora of good and bad software. The whole learning curve is much less aggressive today around adaptability and all you're using personas for now is really to help YOU stay focused (not them) and more over you're really trying to keep the Behaviour vs Incentive matrix intact (Behaviours typically trends upper right while incentive eventually decays...trick is, how long can i sustain the incentive trend).

I wrote a blog post on this here - http://www.riagenic.com/archives/1035

5
  • Oh! Are u here too?!
    – edgarator
    Commented Jan 7, 2014 at 2:18
  • 1
    Wonderful answer and very interesting blog post. I was beginning to feel like I was the only one who was uncomfortable with 'fake people' personas. Commented Jan 20, 2014 at 17:11
  • Edgar: of course! (Sorry all, we both work together for the same company hehe) @StewartDean thankyou! I appreciated that comment.. i felt exposed on my theory here heheh. Commented Feb 12, 2014 at 22:21
  • An example of an exception where age ranges are useful insight would be when around 75% of your users are around 70 years old. This would have effect on the devices used, the environment, the importance of accessibility. But also important: pattern recognition, it works differently and less effectively for the elderly. Commented Jul 22, 2017 at 13:15
  • 1
    I'm just here 6 years late, however, I just wanted to thank you for this! Really loved the blog post. @ScottBarnes
    – onosecond
    Commented Mar 10, 2020 at 9:59
3

The best way to do this would be to go out into the field, to watch your target audience in their own environment and to interview them about their current behavior and what they think their future behavior might be in the future. Take some time to analyze and think about each person. You should interview about 3 people, per persona. Focus on behavior patterns, not idiosyncrasies. The hard part will be finding the users, talking to them, and observing them. The analysis and persona part will be easy.

If you do this, you will find that when you create your personas you will not be pulling information out of the air. You will not need to make guesses about their background or behavior. You will be able to fall back on actual user data to resolve differences of opinion or to make clarifications.

This is the method I learned in grad school in an HCI program, however, there are personas for other related disciplines that are NOT based on actual user data. For it to be truly be called user experience, there must be actual people in your user research. If you do not base your personas on the observations and interviews of actual people fitting your audience, then you need to be honest with yourself that what you have is a work of fiction.

See also this old article from Jared Spool: "When Does A Persona Stop Being A Persona?"

3

I've always learned persona's are meant to be made up. It prevents you from focusing on one person, ignoring the rest for that one person might not be representative for the rest of your target audience. Sure you don't have to make everything up. If you know the different types of people in your target audience you can make personas based on them. You can give your fake person the hobbies of different people of the same group of types. Pick the demography of another person in that group and so on. A fake name will prevent the persona becoming a real person, but together with a real portrait, will make it real enough.

UI faces and UI names are fun webtools related to this.

3
  • The issue I have is that the useful stuff can get thrown away. I've used real people in the past and it's been helpful. I understand issue with fixating on one person (I have to insist that stakeholders never see only one user testing session for example to avoid this). Instead of an age I want to know the age range, otherwise it's just an arbitrary bit of information. See what I mean? Commented Jan 3, 2014 at 16:35
  • @StewartDean Wouldn't you be making a target audience description then, using ranges and stuff like that? A persona could be a real person and is representative for a part of your target audience. Several personas will make up your entire target audience, but they won't contain every bit of information that there is about your target audience. For this reason you should have a target audience description first and make several personas out of this information. Commented Jan 6, 2014 at 10:58
  • The issue is that you should never design for one person. It's the same reasons you insist stakeholders watch more than one usability session. If they watch one then everything will be targeted at that person, who is going to be unrepresentative of all users in some ways. Same problem with personas in my view. Commented Jan 20, 2014 at 16:53
2

Doing this would defeat the purpose of a persona completely.

What you are trying to do is to make an aggregated profile of a stakeholder group. This can be useful for some purposes, but is usually more work than it is worth. It is normally enough to identify each stakeholder group and its goals (including negative goals and fears). Any extraneous information will not help you build a better requirements specification.

The value of personas is to use it when communicating with team members who have little UX experience and cannot relate well to a description of stakeholders with goals and tasks. Making the persona portrait lifelike is what you absolutely need for this.

Example: you are making an application which allows students to enroll in courses. You could surely make a profile which says "student", and write down that a student is anybody from the first semester to the ones working on a graduate thesis. You could write a sentence which says "main goal: get X credits for the current semester". But your product owner, who works somewhere in the university administration, will not be able to do much with it, and will push for an interface fit for using by herself, which will probably have a very steep learning curve.

If you make a persona, you can have Dave, who just arrived at the university for his first semester in economics. He is bright, enthusiastic, eager to try out college life, but also a bit overwhelmed with the fact that mommy and daddy are not here to take care of things. He is also missing his sweetheart who will try to get accepted at the same university next year when she finishes highschool, but right now feels very far away. The introductory material suggested that he tries to get at least 10 credits towards microeconomics, 10 credits towards math and statistics, and to spread the remaining 10 between non-compulsory topics like business administration, or social science, or trade laws. But he wonders if this won't be a bit much and secretly hopes that it will be OK if he doesn't do any math the first semester.

So when your product owner insists on a screen which is structured in the same way as the paper forms she used to fill for students and send to the examinations bureau, you can tell her "I think this is too complicated for students", and she will probably say "They are at a university, they are supposed to be clever enough to fill out a simple form". But if she has read your persona, you can ask her "Do you think that Dave will know where to find the course booking number to fill in this field", she is much more likely to immediately understand that this won't end well, without you having to argue. She has probably seen hundreds of clueless Daves in her career; she just won't think of them when you say the generic "students", so you have to use the persona as the tool to prime her mental associations, and also kindle her empathy and compassion towards the user. The generic description will not work for that.

Aggregate stakeholder descriptions and personas are different tools for a UX specialist, each has its uses and has to look in a certain way in order to work. Create only one of them, or both, depending on whatever you need. But do not create a mix of them, and do not use one where the other would be appropriate.

5
  • 1
    If you product owner is structuring screens then that appears to be a issue with trust in UX. The I have with above is as soon as you start saying 'He is bright and enthusiastic..' etc you have stepped into the world of fiction rather than fact and there is a huge danger that you are in fact building for mythical users not real users. I understand the point of humanising things - but, as someone who use to user personas, would find your personas patronising and unusable. In stead I prefer real life quotes to add life to the my user types and user real life scenarios where possible. Commented Jan 20, 2014 at 17:01
  • Of course personas are fiction. This is the whole point. You should not be using them in the places where actual information is needed. If you can't find a place in your work where fiction is useful, don't use personas. But I, and other people I have worked with and read articles from, find them useful in many situations.
    – Rumi P.
    Commented Jan 20, 2014 at 20:29
  • 1
    I really think you've got the wrong idea of what personas are used for. They are used to provide team members with information about the users. Perhaps you're getting them confused with marketing personas, which are far less useful for UX. If you're using them to get your view across then that's a problem with your organisation. UX should be, where ever possible, evidence based. Commented Jan 21, 2014 at 10:14
  • Actually no. Persona(s) and team recall is a way of trying to create an assumed bias and will always be cherry picked to death anyway. Ux Persona's are a focus for Product Owners to outline who they WANT to target not who they ARE targeting as no matter what happens the moment you create a new or updated experience your essential data becomes invalid anyway (as you've changed the landscape). Also recalling Personas is quite an attack on Working memory for the best of us, aggregate forms of Persona(s) are shallow attempt to reduce cognitive load for recall purposes. Commented Jun 19, 2014 at 10:50
  • Not only does it defeat the purpose, it is simply opposed to the original definition by Cooper. You might want to do as you've described, and it might be a good idea, at least in some situations, but it is by definition not Persona. Commented Aug 12, 2015 at 5:57
1

We had the privilage to do a workshop with our users, and at the same time evaluate their level. These real users where used in development of the software, and we kept photos of them to have their ability up front. It was most helpful and we could discuss what X could do, and if she run into trouble, maybe she could get help from Y - before calling us.

It was fun and a little creepy at the same time. Next step would be to connect them to a facebook group to have that as a dicussion forum. If this counts as "personas", I wouldn't know. But it was fun!

1
  • Given enough users I can see this as a more realistic and useful tool to put team members in touch with real end users. You've avoided the problem I have with composite assumptive personas - they often contain large amounts of useless fiction. Commented Jan 20, 2014 at 17:04
1

Create your personas using a two-stage archetype extraction process.

Working with information collected through your own narrative research makes your personas contextually-relevant and removes guesswork and assumption, while making use of your own skills in perception and interpretation.

Don't expect to get everything 100% right at the first attempt, but you can iterate easily to improve as you go.

1
  • I'm not a fan of stereotyping, no matter how it is worded. Commented Jan 20, 2014 at 16:55
1

I've always thought of personas as a simplified, normalized aggregate of user research. E.g. I have a list of 100 common tasks from interviewing users, the 10 most frequent/important of those end up on the persona document for that group.

0

I've been trying for ten years to use personas and get clients to engage with them, with varying degrees of success.

Least success: the Alan Cooper The Inmates are Running the Asylum kind of persona as described by @Rumi P. Clients find them patronising or oversimplified, as a rule.

Most success: the type of approach you're talking about. They resonate with a client much better

There's something about the descriptions of personae that sets my teeth on edge - and everyone else's too. And if you can't get your stakeholders to buy in to your personas, they are useless

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.