Tasks, Roles, Job Descriptions, and Personas

I've been thinking a lot about user research artifacts recently, trying to crisply define in my head how they all relate. Here's my current thinking.

At the lowest level, we have tasks and responsibilities. I don't think it's useful to separate the two - sometimes things are better expressed as a task and sometimes as a responsibility. Regardless, this is the lowest level artifact from user research... a discrete activity that a human performs.

A role is a collection of tasks that tend to be performed by one person. A person can take on multiple roles, of course, but roles are not split across different people. If they were, then the role is too big. Also, a role does not imply that all the tasks are performed by a person in that role -- sometimes there are tasks that no one performs in a given organization. But the role says that if the task is performed, it will be performed by the same person that does the other tasks in that role. I sometimes refer to this as a "responsibility set" because "role" is easily misinterpreted. In addition, we try very hard to avoid job title-style names for roles. Instead of, say, "Security Architect" (which implies a person), we say, "Security Architecture" (which implies a responsibility).

A job description is a collection of roles that are typically seen performed by a single person in a given context. This is where we start to see a lot of variability among different customers. Very large enterprise customers often show a lot of specialization, where a given job description covers very few roles -- or even a single role. Smaller mid-market customers have more generalized job descriptions, where one person takes on a lot of roles -- the jack of all trades.

Unfortunately, this is where confusion comes in with regard to the "role" term. I often see non-UX people refer to these job descriptions as a role. And these "roles" really mean "I met someone who did this job, so that means it's a role". Of course, this leads to someone else, who talked to a different customer, to start arguing about how that role is different (or worse, WRONG!) at their customer.

Personally (I don't know if there's an industry standard on this), the job description is also where we should start removing tasks & responsibilities from the underlying roles. For example, a specialized job description may include all the possible tasks that might be performed by a role, but the jack of all trades job description will not perform all the tasks from all the roles included in the job description. I think a reasonable argument can be made that this is better done at the persona level, but I prefer to do it here.

It's probably worth noting that, in my experience, many user research efforts skip this artifact and go directly from roles to personas. I don't think that's a bad thing, but I do think there's a distinction between a job description and a persona, so I'm including both here.

A persona is an fictionalized description of how a person might fill a particular job description. This is where personalization comes in, with names, photos, work-life overviews, skill levels, etc. There are tons of articles about personas out there, so I'm not going to spend much time describing them here. To me, the point of personas is to increase the stickability of a job description. It's easier for people to remember "Ralph the database administrator with a secret passion for ballroom dancing who just graduated from UC-Santa Cruz" than "Large Enterprise: Junior DBA".

Of course, personas are not at the top of the user research pyramid - there are other levels above them. But that's a topic for another day.

Anyway, that's how I see the world. I assume everyone else completely agrees with me.

Multiple instances of one persona?

A colleague has run into an interesting problem during the development of some personas... er, personae. They have a situation where there are common scenarios that require collaboration between different people that all have the same job description/role/tasks/responsibilities. In other words, normally it would be a no-brainer that these different people could be represented easily with a single persona because there aren't any significant differences between them that would merit creating an entirely new persona.

But they work together. If you create a single persona (say, "Elvis"), how do you write the scenario to describe the collaboration ("Elvis sends an instant message to Elvis to check on progress...")?

But if we create 2 personas that are basically identical except for the name, then it doubles the amount of reading that someone would need to do to understand the personas. And there will inevitably be confusion on the part of the consumers ("Hey, Elvis and Jerry Lee look almost the same... why did I have to read both of these damn things?").

Oddly, I don't recall seeing any best practices on how to handle this situation, even though I suspect it's a common one. If anyone has any pointers or advice, I'd appreciate it.

Minimal personas

I wonder if there is some minimum set of information needed before you can really call something a "persona".

Do you need a "person name"? Do you need a photo? Do you need any non-domain personal information?

Obviously one of the challenges with personas is that they can be rejected by uber-geek developers on the grounds that they are egregiously cheesy. One way to avoid that is to remove the cheese. Replace the person name with a job title. Don't mention anything about how many cats they have. Include personal information that is directly related to the design of the product, like, "So-and-so clocks out at 5:00 sharp and whatever he's working on gets forwarded to the next shift," because obviously that might impact how easy it is to forward work.

But one of the goals of personas is to ease communication and make them more memorable by talking about a "real" person. Without the cheese, can this be done? Is it still a persona?

37signals doesn't like personas

Jason at 37signals has an interesting post about why they don't use personas:

Every product we build is a product we build for ourselves to solve our own problems. We recognize our problems aren’t unique. In fact, our problems are probably a lot like your problems. So we bundle up the solutions to our problems in the form of web-based software and offer them for sale.

We recognize not everyone shares our problems, our point of view, or our opinions, but that verdict’s the same if you use personas. Making decisions based on real opinions trumps making decisions based on imaginary opinions.

I’ve never been a big believer in personas. They’re artificial, abstract, and fictitious. I don’t think you can build a great product for a person that doesn’t exist. And I definitely don’t think you can build a great product based on a composite sketch of 10 different people all rolled into one (or two or three).

In addition to the post itself, the comments are really well-written with good points made in both directions.

For me, what's interesting is that I am known for not being a big fan of personas, and yet I think Jason is completely off the mark in his criticism. Or, to be fair, he highlights good reasons why 37signals doesn't need to use personas, but doesn't seem to recognize that those reasons don't apply to many other teams - 37signals is not a representative company. They are the exception, not the rule, because they strongly believe that they are the users of their own products. Not only is this unusual, in my opinion it's also not sustainable.

The other mistake he makes is that he thinks personas are meant to replace talking to real people. Of course, the truth is the opposite - personas are the output of talking to real people. For most organizations, it's just not feasible for every person in the organization to talk to real people and have the skills to successfully interpret what they actually mean and not just what they actually say. For the people who do talk to people and do have those skills, we need a way of communicating the results of those discussions to the rest of the team. Personas are one way to do that.

(Of course, it goes without saying that like any technique, there are teams that do personas poorly, but that is a reflection on that team, not the technique)

Are bad personas better than no personas?

The latest UIEtips article has an interview with Steve Mulder about personas. Here's an interesting exchange:

UIE: When design teams don't have the time or budget to perform user research, do you recommend teams create personas based on who they believe the users of their web site or design really are?

Steve: I think personas not based on actual user research are absolutely better than no personas at all. A lot of customer and user knowledge already exists in many organizations, and by looking at the sales, marketing, product, customer support, and tech support perspectives, you can bring all these existing bits of knowledge together into personas without talking to any actual end user. If you design teams can't easily talk with ends users, this is the most effective way to try out personas for the first time.

I understand what Mulder is saying here, but I'm not convinced. The issue is that lots of people think they know about users, but they are often wrong (or myopic based on their own experiences). They rely on anecdotal evidence, faulty assumptions, and personal bias to make design decisions. If you take that and build a persona from it, all you are doing is formalizing the mistake. And that makes it even harder to correct in the future. And in my experience, even if you think everyone understands that these quasi-personas are a first step towards real personas, at some point someone will question the future investment in user research because "We already have personas!"

It's rarely the case that doing something badly is better than not doing it at all.