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.

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.

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.

Explaining UX to 3rd graders

| View | Upload your own

Here's my presentation. It turned out that the biggest challenge was forcing myself to leave out all the things that someone needs to know to REALLY understand user experience and only leave in the few things that a 3rd grader would be interested in... and can understand in 20 minutes.

I'm not sure the prez will make complete sense without my talking points, but I think the flow is fairly self-explanatory.

I gave the presentation this morning and it went really well. Not surprisingly, the idea of designing video games was a big hit with the kids.

BTW, "Tyler" is my son, "Ms. Stephenson" is his teacher, and "Easley" is the name of his elementary school.

Abject terror!

I'm still not sure how it happened, but somehow I found myself volunteering to go and tell my son's 3rd grade class about what I do for a living. Why did I inflict this on myself? How do you explain user experience to a bunch of 8 and 9 year olds? I can't explain it to adults. My mother still doesn't know what I do for a living. Heck, at this point in my career I'm not sure that "user experience" is a big part of what I do... I'm more of an "Opportunistic Firefighter". There's a bunch of fires raging all over the place... far more than once person can tackle... so I look for ones where we have the best chance to put the fire out, then I wade in with my firehouse and see what we can do. Yes, I concentrate on "user experience" related fires, but as I've mentioned before, if you squint enough, everything is user experience-related.

But I don't think I'm going to explain to them what I really do for a living... that would be far too boring and I wouldn't want to embarrass my son that badly. Instead I think I'll explain something about what a software designer does. These kids are computer savvy, so I think they'll understand the concept that a human being somewhere has to create the websites they visit and games they play. And I think they'll like the part about talking to the human beings that will use the software before it's actually done - game testing is something they "get".

But it's going to be a real challenge to keep the conversation at the right level while still doing a reasonably good job of explaining what design is all about. I think I need some good analogies (like building a house). And I need to avoid completely geeking out (which is an obvious challenge for me) and using professional jargon that they won't understand. It's easy to forget how useful jargon is... but try living without it for an hour.

If I come up with a presentation that isn't awful, maybe I'll post it here via Slideshare so people can make fun of it.

Is "consumability" another useless buzzword?

"Consumability" is a term that appears to have been coined within IBM. I'm not sure who coined it or when it first appeared, but I started hearing it thrown around about 5 years ago. At first I groaned and thought, "Oh, great, that all we need... yet another term for user experience." Whoever coined it must have been an executive because it didn't die (grin) and I started hearing it more and more within IBM.

I've since come around and started to really appreciate the utility of talking about "consumability". But what is it? Is it different than user experience?

Carl Kessler, an IBMer who writes the outside-in-thinking blog and wrote Outside-In Software Development (which I reviewed here), has the best definition of consumability that I've seen:
"Your stakeholders primarily want to perform the tasks with your software that directly relate to their business goals. But when they use your software, they'll have to also address some additional tasks that aren't in their direct path toward accomplishing those business goals... We call these meta-tasks... We refer to this impact of meta-tasks as consumability; the more the meta-tasks distract from your product's business value, the less consumable it is."

In other words, consumability is the measure of all the crap you have to go through outside of using the product to directly accomplish your goals.

Is user experience a subset of consumability or is consumability a subset of user experience? Well, the problem I've always had with "user experience" is that it's so ridiculously broad that anything could be claimed to fall under the user experience umbrella. In practice, I think there's a lot of overlap between the two, with a few things that are only in one space and not the other. For example, lowering the price of your product will increase its consumability, but doesn't have an impact on user experience (other than 7th order effects). Likewise, improving the usability of your core business value doesn't increase consumability, because consumability is what you do before you get to the business value.

But there are two reasons I like the consumability term. First, consumability has a very different impact on your product depending on your industry/context/market. For example, consumability is not a big deal anymore for MP3 players. When they first went on the market, consumability mattered more because consumers weren't sure how to get music onto them - or even get music on their computer. Nowadays consumability for MP3 players is little more than identifying the "on" button (which in some cases, like the iPod, is harder than you'd think). On the other hand, in the area of enterprise middleware (my area), consumability is enormously important. Enterprise customers are trying to manage installation and fix levels across huge numbers of servers and development machines. When things get out of synch, bad stuff happens. But they don't buy middleware products because they want to manage installations - that's just something they have to do to reach the business value. As hardware costs shrink and people costs rise, consumability is more often becoming a critical business driver.

The other reason its a useful term is that there's a natural, understandable tendency for teams to want to focus on adding direct business value to their products. During release planning, a common and obvious question is "What's the business value for this feature?" Well, what if your goal is to dramatically improve installation? Obviously the product could be installed previously and (as just stated) customers are not buying your product because they want to install it. So the business value of simplifying install is, um, well... not there. When you simplify install and the new product releases, you don't get to put a bullet down for something new that the customer can do. Sometimes this can be a hard sell, which results in products that are constantly adding new features but over time it gets harder and harder for customers to actually get value from the new features because they have trouble getting to them.

Talking about consumability changes the conversation. Improving consumability means less staffing is required for things that aren't adding business value, it means faster time to value, and it lowers the skills required to get things up and running... and maintain it afterwards. These are things that both planning teams and customers can get their head around. User experience isn't focused enough to make the same points.

I'm not sure whether "consumability" will make any headway outside of IBM, but I think there's a place for it.

User experience practitioner roles

I'm dealing with an interesting situation right now. I'm trying to create a list of user experience "roles" with short descriptions. I'm using "role" here in the usual sense - not a job description but a set of closely related tasks and responsibilities that tend to be performed by a single person. And of course a single person might handle multiple roles.

This has been done plenty of times before, and for the most part it's pretty straightforward. There's a "user researcher" related role, an "interaction designer" related role, and a "usability tester" related role.

But there are a couple places where things get tougher.

First, how does one describe a "UX architect" role in a way that distinguishes it from the other roles. Given that I'm a UX architect, you'd think this would be a piece of cake, but I'm struggling with it. I have plenty of anecdotes that describe what I do, but distilling it down into a short description or bullet points is eluding me.

Second, how do you distinguish between a UXer who does interaction design and a "developer" who does interaction design? Obviously there are plenty of technical architects who spend their time on design and not coding, but we also have non-architects with development backgrounds who spend all their time on low-level design and don't do any coding. Are these people "UXers"? As someone who thinks my undergraduate and graduate degrees did close to nothing to prepare me for my career in user experience, I don't think there's any reason why someone can't "convert" from a different domain to user experience. But I can't shake the feeling that there's something vaguely different about the roles that has nothing to do with ability.

I wonder if all professions are as imperfectly defined as our's, if you're looking at them from the inside?

The Economist discusses user experience

Courtesy of Putting People First, I found this great article on the need to improve the user experience of computers from The Economist.

A few excerpts:

Consider the Nokia 6680 mobile phone, says Adam Greenfield, an expert in computing culture at New York University and the author of “Everyware”, a book about the future of computing. He found that 13 clicks were needed to change its ringtone. “It's an interface designed by engineers for engineers,” he says.

...

Making computers simpler to operate would help the people who use them and the companies that produce them. Ease of use is one area where technology firms can differentiate themselves and gain competitive advantage.

...

But making computers simpler to use will require more than novel input devices. Smarter software is needed, too. For example, much effort is going into the development of “context aware” systems that hide unnecessary clutter and present options that are most likely to be relevant, depending on what the user is doing.

...

Cars fitted with sensors and cameras collect data on the driving styles of test participants, including their acceleration and braking patterns, assertiveness in changing lanes, and so on. The navigation computer then picks a route that accommodates each driver's strengths and weaknesses. The system works fine—but when drivers are told what is happening, they get angry. This suggests, says Mr Dey, that contextual computing needs to be discreet: such systems are, in effect, judging people and trying to influence their behaviour. Systems that manipulate people, he says, may have to keep quiet about it to work.

Good stuff.

Rating UX practitioners

Joshua Ledwell has an interesting post over at Compete On Usability called "UX practitioners rated." The comments are also worth reading, because Lou Rosenfeld, who runs the UX Zeitgeist page, has jumped in with some explanations of the effort.

I had to jump in as well.

(Side note: I originally only used Joshua's first name in this post, but then I thought, "Without the last name, Yahoo won't know who I'm talking about, and Joshua will lose some well-earned zeitgeist! Better add the last name..." )

iPhone user experience presentation

Courtesy of Usability News, I found this slideshow about user experience created by the team that helped design the iPhone. This is nothing new to UX practitioners, but it might be useful when selling UX to stakeholders.

grokdotcom: Better "usability" isn't always the answer

Howard Kaplan over at grokdotcom has posted a little rant about usability. For example:

About a month ago, I had the opportunity to speak to a group of Usability professionals. The theme of my talk was getting them to raise the bar within their industry; to become true advocates for consumers like they should be. Yes, consumers, not "users". B2B, b2C, self-service, e-commerce, video, web2.0, no matter the focus of your site, or whether a nickel changes hands, your audience consumes the content you provide and engages with the experience you've planned.

And a littler later:

I often challenge people to come up with positive associations with the term user. I'm still waiting for one positive response. Sure, I've heard "Mac user" and even that falls flat given the very real problems with technology — yes, even with Macs — that rear their ugly head at the most inopportune of times.

This is interesting on several levels. First, I find the crusade against the term "user" to be deeply amusing. Howard wants positive associations with the term user? Okay. How about the thousands of times when a usability professional has been in a meeting and said, "We can't do it that way because our users will never figure that out" (or words to that effect). It's an internal industry term that is perfectly useful, and is not in anyway derogatory in the way it is used... quite the opposite. 90% of our job is to treat users with respect... and the other half is to make users happy.

I also find his use of the word "consumer" to be interesting. I would argue that "consumer" is not a synonym for "user". In fact, at IBM we use a term called "consumability", which is not the same as "usability", though there's clear overlap. Consumability is concerned with the front end of user experience. How does a potential customer find out about a product or its features? How easy is it for them to acquire the product? How much does it cost? How easy is it deploy and maintain? How much additional training is needed to be productive? As you'd expect, the is a clear intersection between marketing and user experience in issues of consumability. On the other hand, it's important to remember that in large enterprises the person who chooses to buy a particular product is often not the person who uses the product. Which leads to differences between consumability and usability. For example, price is a good example of something that I would consider critical to consumability but not a factor in usability. Likewise, providing optimizations to increase the productivity of expert users is something that is important to usability but not a factor in consumability.

Later, Howard says:

What brought on this little rant? Our friends across the pond at E-Consultancy came up with a list of their hall of fame "User Experience gurus" based on a survey of their audience. Our esteemed founders, Jeffrey and Bryan, were selected for the list. Flattered as Jeffrey and Bryan were, those who've followed our work over the years know our collective disdain for the casual use of the "guru" label these days.

In case you didn't read Robert's post from last week, where Jeffrey suggests that we marketers need to "get over" ourselves, it should give you some context. A few days later — while, as Jeffrey put it, the woman behind the counter at his local Starbucks still didn't know who he was despite all the publicity – another list came out with an amendment to the E-Consultancy list where both Seth Godin, and Eisenbergs were left off. This new list was created by David Armano, who runs the widely popular Logic + Emotion blog. (If you haven't read David's stuff, his manifesto is what converted me into a regular reader. Although I often disagree with his approach, Logic + Emotion comes highly recommended.)

David's perspective in removing Seth, Jeffrey & Bryan was that they're too much in the marketing camp to be considered "User Experience". My question, though, is this: "Would you prefer to have the experience designed by a top Information Architect but never planned with a deep understanding of the audience's needs? Or would you prefer to plan the experience according to human motivations, then adjust the architecture to match?"

I think you know my answer.

My answer is that it is not an interesting question because both approaches would be broken. I would also say that one of my frustrations is people who think that the "user experience" of a product is the responsibility of the user experience team. It's not. It's everyone's responsibility... including marketing. Just like the "quality" of a product is not the responsibility of the test team. So I fully acknowledge that marketing has a central role in user experience. That doesn't make marketers into user experience professionals though - it's still a different skill set. It's the collaboration between the skill sets (and many others) that creates a good user experience, so trying to figure out which skill set is easiest to drop is not a useful exercise, IMO.