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.