9

Why I provide a lengthy description of my case

StackExchange strives to have general questions with general answers, so that these can help the most people, and not just the person asking. So I normally try and ask such general questions by abstracting away the specifics of my questions. However, again and again, I experience that when doing so, people give too vague answers (no, not general, but vague, because I am perfectly happy with a general answer as long as elaborate and fulfilling), and they often comment “Why do you even want to do that?”. So here is a pretty full decription.

My case

I'm doing a school project, but obviously I pretend this is a real product development process. I have to develop an interface for managing and surveying heat pumps for central heating. Such heat pumps all have a user interface, typically a small, primitive, monochrome display with a few buttons for navigation. The basic goal of the project is to provide a better interface; better and easier interaction and perhaps with more features, probably in the form of a wall mounted panel similar to a tablet pc.

Necessary administration features include:

  • Adjusting temperature, easily, and not permanently. A heatpump tries to keep a constant temperature in the building, and generally does it quite well, but under some circumstances it is off, and the user wants to adjust up or down. This adjustment happens either a few times in a week, or maybe just once a month, depending on the installation and the users.
  • Adjusting the heat curve. The heat curve defines the target temperature of te circulating hot water, depending on the outdoor temperature. Ideally the correct heat curve will make it possible for the heat pump to keep a constant temperature at any climate. Users typically manipulate the heat curve a few times in the first months after installation, and then perhaps never again.

Potential, but not strictly necessary, additional features:

  • Letting the user read, in an easy and intelligible way, the energy consumption. This is sometimes available in some way, on existing heat pump interfaces. But because of the limitations of the rather primitive physical displays, such features are hard to make easy and intelligible, and are rarely used.
  • Letting the user see details about the heat pump, eg energy flow, ground temperature, outdoor temperature, temperature of forward flowing water, etc. I imagine some users are interested in such additional information, just like some computer users like a bar that shows CPU and memory usage.

Discovered information about the interviewees

I've conducted interviews and many of the requirements and preferences (both explicitly said by the user, and my interpretations based on their general (technical) interests and of their use of existing heat pump display). I've interviewed five persons. And they fall very nicely into four well nice categories. The below is actually not personas, but are the people I actually interviewed. The three in the “average user” category, are so similar that I summarize them as one. It is not a forced creation of a persona.

  • One person. Super user. Engineer, understands his heat pump and central heating system very well. Loves to play with it. Even understands the physics of thermodynamics. Has many ideas in his mind of how the heatpump could be optimized.
  • Three persons. Average user. Male. Loves his heat pump, like he loves his car, because he is impressed by the technology. Also he is very interested in the economics, how much money it saves compared to using oil.
  • One person: Female. Lives alone. Does not care about the heating system, and even more uninterested in the technology or the physics. Hates interacting with it, so she never does so.

How do I create personas, and why even make them fictive?

Now I want to create the personas. The average user is pretty easy. I extract the most obvious shared characteristics, and for the aspects where they differ, I pick from one of them or define it slightly differently. I keep it very specific, though not necessarily accurately (as any of the interviewees).

There there are the other two. Why should I write the persona any different from the actual person? Is it even a persona if I use her actual details? I understand, if she had any really strange quirks, I could benefit by weeding those out. Fx if she was afraid of the dark in the basement, and therefore do not want to go there. But both these specific persons do not have any quirks that I believe I see any reason to weed out.

The woman divorced her husband, and now runs a riding school at her property. She says that her riding school takes all her focus, and that's why she hasn't cared to try and understand her heat pump. She says that “I don't understand technique, but I know something about life”. Though she dreads touching the heat pump, she does not get frustrated or annoyed when having problems, she just does not care, and finds other ways to deal with it. She likes to stay up late and read. Sometimes she would like to raise the temperature but she is so afraid of doing something wrong that instead she lights up her wood stove, even when she would have preferred just to turn a knob to raise the temperature.

Why would I want to change any of that into a fictive persona?

No, not a duplicate

This question is not a duplicate of Why Not Use a Real Person as a Persona?, since this question is much more specific about an actual person constituting a perfect persona.

4 Answers 4

5

I think this is primarily a question of ethics. Please note - I am not questioning your ethics by any means, these are just general thoughts on the ethical side of user research and persona creation.

In conducting user research and interviews, we are responsible for keeping the users' identities confidential. Using the user data you have collected to create a persona (rather than using specific details/traits of a user) reduces the likelihood that the user could be recognized if someone were to review your research. While this may seem like a more serious issue for some projects more than others, it is still a good practice to get into.

I realize that available users, budget, and timeline all play into the amount of research you are able to perform. However, do you feel that you may gain a deeper understanding of the workflow preferences and issues faced by the first and third user groups if you were able to interview more users that fit in those groups? By basing a persona off a single user, you may be missing some crucial data and project requirements that could be uncovered as you meet with more users and conduct more research.

2
  • You are right about the ethics. It depends a lot on the situation though. A user might be perfectly fine with using her actual occupation, etc., especially if these are so general that it's hard or impossible to identify her. Aug 17, 2015 at 17:41
  • I agree, that most likely I would gain more information by doing more interviews, however in this project that was just not possible. And of course, if I had more than one user contributing/adding to a persona, the whole idea about making a fictive persona makes more sense, even if one of the persons does constitute a perfect persona. Aug 17, 2015 at 17:44
3

As @Andy writes, you run the risk of invalidating your research (or worse) by not adhering to best practices re: confidentiality.

The other problem I see is that your example real user may be too specific to represent very many people. Your, "lives alone, doesn't want to touch the heater" persona can be quite effective without the colorful details about your actual users. In fact, this persona can be even more effective if it is more generalized, and relies more on traditional persona data like painpoints, must-haves, motivators, rather than a detailed narrative.

For example, a more generic persona might apply to guests, babysitters, or children, who may share much in common with your "lives alone" user, like not understanding the system, not wanting to break anything, not interested in learning more about it. If your persona is too specific, it won't represent them well.

2
  • Thanks. When reading about persona, most of the guidelines and advice are the opposite of yours, including the following from the original "The Inmates are Running the Asylum". There is a whole section called "Be Specific", fx: "The more specific we make our personas, the more effective they are as design tools. That's because personas lose elasticity as they become specific. For example, we don't just say that Emilee uses business software. We say that Emilee uses WordPerfect version 5.1 to write letters to Gramma." Longer excerpt: jottit.com/b3zcg Aug 17, 2015 at 17:36
  • Excellent point and thanks for the reference. You are right, personas become less effective when they get too generic. I suppose I would rephrase my advice as: limit the specific details to those that are most pertinent to the persona as user. Other personal details may or may not be relevant, depending on the product. This is why, for instance, Marketing personas typically contain a lot of things I wouldn't put in a product/ux persona. Aug 17, 2015 at 17:45
1

Using fictive personas is also handy when you want to illustrate insights you gathered not only from user interviews but from different sources. Like quantitative surveys or ethnographic field studies.

For exemple, if your research shows that 30% of your customers live outside of the US, you want your personas to represent that insight. Even if the users you talked with all live very close to you.

In your very case though I don't see no requirement for using real info except what have been discussed above!

3
  • I totally get your point, and I had not thought about that. But I would like to discuss it though :) According to Cooper, specificity is crucial, but actuality is not. So just because 30% lives outside USA, no persona has to reflect that, unless living outside USA makes a crucial difference in the use of the software that is not already reflected in any persona. I like the idea though, to weave such a statistical fact into a persona when it makes sense. Aug 20, 2015 at 5:37
  • Here is a more philosophical comment, only peripheral to your comment :) One reason of making up all the specific personal details, according to Cooper, is to make the personas more real to the developers, give them a personality. If you want the developers to associate with the personas, perhaps that is easier if they are types of people that the developers know. So fx if 95% of customers live in Nepal, but that fact has no effect on the use, then perhaps its still better to make the persona from a Western country (if the devteam are Western). Aug 20, 2015 at 6:09
  • A teenager in Nepal and one in USA probably play Angry Birds the exact same way. But maybe a persona of a poor village kid in Nepal is distracting to developers because they imagine the teenager's life, daily routines, etc. different from what they actually are. I don't have any conclusion to this, I just think it's an interesting question :) Aug 20, 2015 at 6:11
0

In addition to the other answers, I want to add.

Personas allow for later revisions.

During the coming steps in a development process it might suddenly be evident that the persona (no matter how it's constructed) needs different qualities, or just additional qualities (ones where we actually don't know the value of the real user). One example is foreign language proficiency which we forgot to ask the interviewee about. Then perhaps we want to add that she does not speak Spanish. Perhaps the real person does, but it really does not matter, we just want the persona to not speak Spanish. In that case it is suddenly nice to be able to revise the persona. Of course it could also be possible to revise the "real person", which then becomes a kind of persona. But then the personas and the persons they are based on get mixed up.

Your Answer

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

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