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.

Cash or Personal Check Only

The user experience problems associated with the Department of Motor Vehicles are legendary. It seems trite to even complain about them... it would like ordering a cheeseburger from McDonald's and then complaining that it didn't taste very good. True? Sure. Interesting? No.

But I couldn't let this go.

I renewed my driver's license this morning. In North Carolina, it costs $32, which seems pretty reasonable for something I only need to do a couple times a decade. But when it came time to pay, I couldn't do it. They only take cash or personal checks.

Personal checks?!? I don't remember the last time I wrote a personal check. If I needed to write a personal check, I'd need to ask my wife where she keeps them.

But personal checks aside, how is it possible that the DMV does not accept credit cards or debit cards in the Year 2009? At first, when I was driving around trying to find an ATM machine so I could pay for my new license, that was a rhetorical question born out of my exasperation. But then I thought, "Really... why don't they take credit cards?"

Here's what I came up with:
1. No one chooses to go to the DMV. We only go there when we have no other choice. And we can't choose to go a different, better DMV vendor. And the DMV isn't trying to drive up their customer numbers. There's no profit to attracting new customers, so the customer experience simply doesn't matter. Sure, it would make life easier on us if they took credit cards, but there's no clear incentive for them to want to make life easier for us.

2. Like large corporations, the government has a rollout scale problem. Sure, it would be really inexpensive to add a credit card payment option to my DMV location. But it's expensive to do it for every DMV location in the entire state. And phased rollouts are difficult for political reasons (who gets them first?) and in some cases, Equal Protection laws can make phased rollout unrealistic (though not in this case, I think). But the point is that pervasive change is hard to do on really large scales, even when the change is innocuous on a small scale.

3. I'm sure credit card machines would save the DMV money in the long run. There's a reason businesses are starting to refuse personal checks and encourage credit cards. But if you are an elected official, are you going to vote for something that will cost money now, but save money in the future, with a break even point well beyond your current term? Long term strategy is not rampant in the government.

Those are my theories anyway.

By the way, I took that picture in the DMV office this morning on my cell, so I apologize for the poor quality.

R.I.P. Sheila Bleizeffer

If memory serves, it was in early spring in 1996 that my wife Karen was volunteering at the SPCA, and she asked me to come in and meet one of the dogs. We already had Indigo (an Australian Shepherd) at this point, who was a handful, to say the least, so after the requisite browbeating I agreed to go in and meet this dog. I insisted that I was only going to meet the dog, but we were not bringing the dog home that day... which just goes to show my level of naivete at that point in our marriage.

We came home with Sheila that day. Her given name was "Shula" (maybe her original owners were Miami Dolphin fans), and given that she was an Australian Cattledog (mostly) and she was female, we decided to change her name slightly to Sheila. Get it? Australian female? Sheila? Yeah, we're clever.

Sheila died in my arms around 3:45 today, June 29th, 2009, after the cancer in her jaw and throat made it difficult for her to breathe. She stopped eating yesterday, and she couldn't sleep because it took too much effort to breathe to relax enough to sleep. It was her time.

Sheila was the antithesis of Indigo. Indigo was too smart for her own good (it's never good to have a dog that is smarter than its owners). She was willful and mischievous... and we loved her. She seemed to take a perverse enjoyment out of pushing our buttons.

But not Sheila. Sheila was eager to please. If she ever misbehaved, it was obviously a mistake because she would be devastated to think that she had done something wrong. Indigo thought anyone who came to the door was Jason Vorhees incarnate. Sheila thought everyone was a potential friend.

Our cats would rub up against Sheila's legs and spoon with her when she was sleeping. And she wouldn't complain.

And she purred when she was happy.

When he was a baby, our son Tyler used to gleefully grab Sheila's fur and hold on tight until he got bored or Sheila's fur detached. Sheila never complained.

Our daughter Carson has a friend named Rebecca. She invited Rebecca over for a playdate, but Rebecca and her mom were concerned because Rebecca was deathly afraid of dogs. We told them "You've got to meet Sheila." They met. Rebecca is no longer afraid of dogs... in fact, she now wants to get a dog of her own.

Old age was not particularly kind to Sheila. She developed arthritis and had bouts of severe joint pain over her last couple of years. At one point it got so bad that I built her a ramp to get up the two steps from the sidewalk to our front porch, and I was convinced that she didn't have much longer. Then, amazingly, she recovered. She still had trouble and couldn't make it up the stair to the second floor, but her mobility increased enough that worries about her quality of life went away. For the last two years it felt like we were living on borrowed time.

Then, a little over a month ago, she started snoring while awake. A quick Google search suggested it was probably allergies, so we switched her food, but it didn't help. So I took her to the vet and they found severe cancer in her jaw and neck that was obstructing her nasal passages and throat. There was nothing to be done at that point but try to make her comfortable. The pain medication helped a little, but when she stopped eating we knew it was time.

Of course, the thing I'll miss most about Sheila is that she loved me far more than I deserve. We all need as much of that in our lives as we can get.

Goodbye, Sheila, I love you too.

Killer robots want good user experience too!

Dr. Pete has posted a presentation on his blog called "Attack of the Bad Usability!" that deserves more than just a shared feed... short, funny, and informative are three things that go great together.

Check it out.

Nielsen says to stop password masking

Jacob Nielsen says that we should Stop Password Masking in his latest AlertBox article. His argument is simple -- we are very, very rarely in a situation where we're typing in a password while someone is looking over our shoulder. It's extremely common for us to be typing in a password when we're alone. So why not showing our passwords as we type? And, he suggests, have a checkbox to mask the password for those rare situations when someone actually is watching us type.

This reminds me of a situation I ran into a few years ago. A server product I was supporting got complaints from customers because we were showing passwords in property files. A central aspect of security for the server was file system security, so there was no issue with an unauthorized person being able to open the property file and see the password (if they could do that, they wouldn't need the password, the entire system would be vulnerable). So the issue was solely around looking-over-the-shoulder scenarios where someone would need to open the property file with someone watching. There was a clear usability degradation from occluding the password in the file, so we asked customers to give us examples of situations where this looking over the shoulder would be a problem. Their response? It doesn't matter! Passwords should always be occluded! Just in case!

We masked the passwords in the property file.

So I have a lot of sympathy for Nielson's position. But I'm not completely convinced. For example, the one fairly common scenario I can think of where masking is needed is when screen sharing during a web conference. I'm on web conferences all the time, and I'd estimate that there are at least a couple times a week where someone types in a password while screen sharing. And note that Nielsen says that some passwords (like for bank accounts) should perhaps be occluded by default, but there's nothing special about passwords when screen sharing. In other words, during design we can't anticipate whether this is a password that is likely to be used during a web conference. If users have to click a "mask" checkbox before typing a password in a web conference, lots of people will forget... potentially exposing their password to not ONE person looking over their shoulder, but scores of people on a web conference. That seems like a very real concern.

But in terms of baby steps, I like the idea of having a checkbox to mask passwords that is always checked by default. If you're surprised when you first password attempt fails, you can uncheck it and make sure you're typing in it in correctly.

Mr. X and Dustin Curtis

Via a Tweet from @uxforward, I encountered Dustin Curtis's admonishment of American Airlines, the reply from a UX architect at AA.com (and Dustin's response to it).

I love the internet.

Anyway, I found this exchange to be fascinating. The main thing that resonated with me was Mr. X's statement:

But—and I guess here’s the thing I most wanted to get across—simply doing a home page redesign is a piece of cake. You want a redesign? I’ve got six of them in my archives. It only takes a few hours to put together a really good-looking one, as you demonstrated in your post. But doing the design isn’t the hard part, and I think that’s what a lot of outsiders don’t really get, probably because many of them actually do belong to small, just-get-it-done organizations. But those of us who work in enterprise-level situations realize the momentum even a simple redesign must overcome, and not many, I’ll bet, are jumping on this same bandwagon. They know what it’s like.

Amen!

This reminds me of the book review I did on Robert Hoekman's "designing the obvious". In the review, I said, "The only major problem I had with the book, and it's not all that major, is that it was written with an assumption that bad design happens out of ignorance for many of the principles he is espousing. That people are not doing things the right way because they don't know the difference between the right way and the wrong way. Clearly, this is sometimes true, but I think it's the exception to the rule (at least it is the exception when there are professional usability people involved in the project... and the audience for the book seems to be professional usability people)."

To net it out -- coming up with a good design is the EASIEST part of creating a well-designed product. Hell, it's almost trivial.

Dustin thinks this is a cop-out. In a sense he's right - it's a cop-out from the perspective of American Airlines as a company, but it's not a cop-out from the perspective of Mr. X. American Airlines, like any large corporation, has to figure out how to deliver well-designed products in spite of the difficulties that come from being mammoth. But Mr. X wasn't excusing AA from responsibility and he wasn't saying that nothing could be done. He was just pointing out (far more politely than I would have) that's Dustin's belief that the problem with AA.com was that no one could tell good design from bad design was hopelessly naive.

Of course, Dustin's argument that the problem must be that AA's CEO lacks "taste" doesn't dispel the naivete charge. Dustin's heart is in the right place, but I think he really doesn't understand how large enterprises work.

Killing zombies in the name of user experience

Like most user experience folks, I'm a geek. Sure, we're not geeks compared to most of the developers we work with, but they are not a very good baseline for geekdom. I suppose it makes us feel good to know that on the geek scale, we're George Clooneys in comparison to developers. But compared to, you know, normal people, we're somewhere between Michael Bolton and Matt Farrell.

Anyway, my point is that I'm a geek, and nothing says "GEEK!" like expressing my masculinity by sitting in my recliner, drinking a beer, and killing virtual zombies on my XBox 360.

Enter Left 4 Dead, which is remarkable in lots of ways, but mostly because it was designed from the ground up to be a four-person collaborative online game. You can play with fewer than 4 people, but it's something you only do when none of your friends are online and your trigger finger is getting twitchy.

But this isn't a review of the game (which is great and you should go buy it now). One of the interesting aspects of Left 4 Dead is that it's very, very short. There are 4 campaigns that you can play, and each campaign takes about 90 minutes (depending on the difficulty setting) to complete. These campaigns are all independent from one another, so most people will play through one entire campaign from beginning to end each time the play the game. And due to endless variety in zombie spawning, each time through a campaign is unique.

This led the Left 4 Dead crew with a problem. How do they teach people how to play the game? Most games have an initial "training stage" at the beginning of the game to teach people the basic game mechanics. But going through a training stage at the beginning of every 90 minute campaign would get annoying quick. What to do? Fortunately, the folks who created Left 4 Dead have a blog and explained their innovative solution: creating an entertaining intro movie that teaches the important aspects of the gameplay.

Because Left 4 Dead is a new property for us, we wanted to provide some basic player training prior to the start of the game. Traditional in-game training mechanics didn't make sense for Left 4 Dead, because they would take away from the sense that players had been immediately dropped into a very real, very dire zombie apocalypse. We didn't want a slow ramp-up in gameplay to take away from that tension. As a result, we decided that it would make sense to begin the game experience with a non-interactive introductory movie that could get players revved up and subtly cue them to important gameplay mechanics such as "light disturbs the witch" and "car alarms attract the horde."

Starting a game with a movie was a new approach for us, but luckily we have built up some moviemaking expertise in the past few years with the Team Fortress 2 shorts. In this blog entry, we'd like to share with you some insight into the process that led to the intro movie that shipped with Left 4 Dead. To do this, we will show four different versions of the first half of the movie from various stages of production.

Great work, Valve.

Now my trigger finger is getting twitchy...

Merry Christmas to me!

I'm trying to think of some really clever way to tie my purchase of a Mini Cooper to user experience (something about emotional design, I think), but who am I kidding? I'm just posting this because I'm excited like a kid in a candy store, and I don't care if it's off-topic or not!

Faux simplicity

It's finally gotten cold enough here in North Carolina (it's 24 degrees outside right now) that I climbed up in the attic and got out our space heater for the kids' playroom. In doing so, it reminded me of one of my least favorite design techniques - what I call "faux simplicity". Take a look at the control panel for the heater:



Wow... it's soooooo simple that it only has ONE button! They even advertise the "1 Touch" interface below the panel. What could be simpler than one button?

How do you turn it on? You click the button.

How do you turn it up to the next degree setting? You click the button and the temperature goes up one setting.

How do you switch it from high to low? You keep clicking the button as it toggles through the high and low temperature settings.

How do you set it be always-on? You click the button until none of the temperatures are lit up.

How do you turn it off? You click the button and hold it down until it powers off.

SIMPLE! One button!

As a real life example, I usually have it set to Hi and 75 degrees. My kids wake up and they're cold so they click it twice (once to Hi/80 then to Hi/Always-on). Then I walk in, irritated, and tell them that the heater doesn't get any hotter just because it's set to always on (they think 75 degree is the temperature that the heater is running at, not the temperature that it shuts down automatically). So I want to switch it back to Hi/75. By clicking the button TEN TIMES.

1. Lo/60
2. Lo/65
3. Lo/70
4. Lo/75
5. Lo/80
6. Lo/Always-on
7. Hi/60
8. Hi/65
9. Hi/70
10. Hi/75

Woops... I clicked too fast and ended up on Hi/80. Now I need to click 11 more times to move it down one degree setting.

By having a single button, they didn't make it simpler, they made it more complex. They didn't simplify the feature set, only the interface, by overloading their single button with a bunch of different capabilities. The interface would be much simpler with an on/off button, "temp up" and "temp down" buttons, and an "always on/temp control" toggle. In this case, 4 buttons is simpler than 1.

The iPod has a similar example of this - the fact that you need to turn the iPod off by clicking and holding down the Pause button. This annoys me everytime. Please, people, On/Off buttons do not add unnecessary complexity in items that are turned on and off repeatedly!

We experienced this in one of our products a few years ago. Customers were complaining that our install was too difficult. At the time, our install process accomplished two things: it asked the few standard, necessary questions so we could put the product onto the machine (install directory, etc.), and a few questions that were required as "pre-configuration" so that the product would work the first time you used it (to our credit, we had reduced this set down to a bare minimum). So what was the proposal to simplify install? Simple! We'll separate the install into two parts! One part is the normal install that you see for every product and the second is a post-installation configuration wizard. By pulling the configuration out of the install, we'll make install way simpler!!

Of course, that's not simpler at all. From the customer's point of view, "install" translates to "all the crap I need to do before I can get the product running", including the post-installation/pre-configuration stuff.

We began referring to this as "small i" install and "big I" Install. Small i install is the "putting the bits on the box" process, and big I Install is the whole enchilada for completing and managing the installation. And we were able to successfully make the point that shifted some complexity from one place to another within the Big I Install is not simplifying anything for the customer, it's just changing where they encounter the complexity.

As discussed previously, "simplicity" is not a valid goal... it's a distraction.

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.