Subscribe: The User Experience Soapbox
Added By: Feedage Forager Feedage Grade A rated
Language: English
consumability  don  experience  job  make  people  person  personas  product  sheila  time  user experience  user  work 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: The User Experience Soapbox

The User Experience Soapbox

Rantings and ravings about user experience, with a focus on the user experience of enterprise software

Updated: 2018-01-15T11:31:51.491-05:00


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


(image) 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 (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.


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 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/602. Lo/653. Lo/704. Lo/755. Lo/806. Lo/Always-on7. Hi/608. Hi/659. Hi/7010. Hi/75Woops... 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.

Null sets in girl's bikes


It's Christmas time and I'm thinking about buying my 8 year old daughter a new bike. I'm trying to find a bike with 20" tires that also has multiple speeds (she has a single speed bike now and is getting frustrated that she can't shift gears on our bike rides). So I was looking at some bikes on and ran across this:
Note the bullet points at the bottom...

- 20" Wheel Size Fits Most 6 - 11 Year Olds
- Recommended for Ages 12 yrs. and Up

So I guess they are marketing this bike to short 12 year olds?

UPS: Worst customer experience of my life


I was in Barcelona last week for a customer conference. Yes, envy is a natural reaction to that statement. I was running a series of customer feedback sessions throughout the conference, and as preparation for these sessions, I shipped a box of materials to Barcelona via UPS. This turned out to be a mistake of colossal proportions. To understand just how ridiculously bad UPS handled this shipment, I need to go into boring, gory detail and describe step-by-step the series of events that took place. For those who understandably don't want to read the full narrative I will summarize it in one sentence: The box arrived in Barcelona on Tuesday the week before the conference but never made it to the conference center... I finally gave up on it nine days later.Here's the full story:I received shipping instructions from the conference coordinators, and they requested that boxes should arrive on Wednesday, Thursday, or Friday the week before the conference. The conference began on Monday, with some early registration on Sunday night. One of the things in my box was 800 flyers to be inserted into everyone's conference messenger bag that they receive when they register, so it was important that the box be waiting for me when I arrived on Saturday so I could do all the inserts. To make sure this happened, I sent the box out the Friday before it needed to be there and specified a Wednesday delivery.On Tuesday afternoon, I got a call from UPS. They said they tried to deliver the package, but they weren't able to do it because the recipient wasn't there. I told them to re-deliver it the next day (as originally scheduled), and I was encouraged because I knew the package had made it to Barcelona... early! Great, no problems.I arrived on Saturday and the box wasn't there. And UPS was closed on Saturday and Sunday. No useful information in the tracking information online. We called UPS in America and tried to get a number for someone in UPS Spain - no can do. We said, "Listen. You work for a multinational corporation. I work for a multinational corporation. I guarantee that if I had to get someone from IBM Spain on the phone on a Sunday, I could do it." The UPS person said, "I can't even make international calls."So on Monday morning we called UPS -- they opened at 9:00 AM. They said the problem is that they can't deliver the package because it's stuck in customs and they need someone to fax over a passport. Of course, they'd previously said they tried to deliver it on Tuesday, but the person had no record of that happening. We asked why they hadn't called to let anyone know about the problem... they said they weren't sure. So we asked how long it would take to get through customs, and they said, "A few days." We asked them to expedite it and they said they'd try and to call back that afternoon for more information.We called back Monday afternoon and they said it hadn't cleared customs yet. They told us to call back in the morning.We called back on Tuesday morning and they said it hadn't cleared customs yet but they expected it to clear that day, so we could call back in the afternoon and either pick it up ourselves or arrange deliver the next day.We called back on Tuesday afternoon and it had cleared customs! Yes! We said, "Great, we'll come to pick it up right now." And they said, pick it up? No, you can't pick it up. We have to deliver it. Tomorrow. Okay, fine. We asked them to mark it urgent so it would be delivered in the morning. They said, "It wasn't marked urgent when it was shipped." We explained that things had changed since it arrived in Barcelona a week ago. They said, "No, we can't change something from not urgent to urgent. It will be delivered sometime on Wednesday, but we can't give you any i[...]

Hmmm... that's a good question


I wonder what the consequences are for picking the wrong answer?

Helpless Desks


My old basic G router was starting to have some issues, so I decided to upgrade to a new Wireless N router. I installed it last Sunday night to be sure everything was working for Monday morning. I work at home full-time, so I didn't want to spend time doing router configuration during work hours. Fortunately, the configuration was fairly painless (even though I had to configure 3 laptops, 1 desktop, an XBox 360, and a PS3 to communicate with the new router). Security was turned on, of course, and I tested the internet connections on all the machines and everything worked fine... and I went to bed content.

When I got up the next morning the first thing I did was fire up my program to tunnel into my corporate intranet (which I run non-stop throughout the work day). And it didn't work. My internet connection was working fine. The tunneler was successfully communicating with something. But no access to the intranet. Dang. So I troubleshooted for awhile and got nowhere.

Finally I called the Help Desk for my company's intranet. The first thing they asked me to do was bypass the router and connect directly to the cable modem. The tunneler worked fine, which meant that it was definitely an issue with the router. But they don't provide support for routers, and as far as they were concerned the tunneler was working fine, so they closed the ticket and hung up, telling me to call the router Help Desk.

So I called the Router help desk. The first thing they asked me was whether my internet connection was working. I said it was, which meant it was a problem with the tunneler. They don't provide support for the tunneler, and as far as they were concerned the router was working fine, so they closed the ticker and hung up, telling me to call the tunneler Help Desk.

I'm not making this up.

2 hours later I fixed the problem on my own. Apparently the new router (unlike the previous router from the same manufacturer) didn't support IPSec, which was what I was using in my tunneler (by default, not via a configuration choice I had made), so I switched my tunneler config to use SSL and that worked.

So was it a tunneler problem or a router problem? Well, clearly it was both. The problem was that I needed to have the configurations in the two programs working correctly together. This is not an unusual situation. It's bizarre to me that in this day and age Help Desks still seem more interested in closing tickets than providing actual help.

Verifying 911 service in VOIP


I work from home full-time and I recently decided to switch my second phone line (my business line) to VOIP to save the company some money. I'd been avoiding it because I'd heard negative comments from co-workers about the quality, but the money I was being charged for my nearly constant teleconferences finally made my decision.

And I'm delighted with the change. I haven't had ANY connection quality issues, even when I'm screen sharing at the same time. It's been crystal clear and reliable. And everytime I make an hour-long long distance call and remember that it is costing me nothing, I smile a little. It's wonderful.

Except for one thing. Every couple of days I'll make a call and a voice will tell me that before they can connect me I have to verify my 911 service is still the same number that they have on file. First, I have no idea why they need to keep asking me this. But even worse is that it won't register my keypress until it has spoken the entire message AND all the options. I've heard this message so often I've started hearing it in my sleep... and yet I have to wait to listen to the whole thing, everytime, before it will let me press "1".

I still love VOIP, but somebody needs to fix this.

Proof of the difference between survey results and truth

2008-06-26T16:11:03.382-04:00 had an article about the recent results of JD Powers' survey of recent car purchases, and which cars consumers liked the most. Here's what they had to say about the VW Passat, the winner of the mid-sized car category:


Huh? "The Passat's drivetrain was a particular high point among owners..."

They should have followed that statement with "... which proves that our survey is so poorly constructed that the results are completely meaningless."

Now, I freely admit that no one would describe me as a car wonk. I don't spend weekends rebuilding carburetors or swapping engines out of 1968 VW bugs. I've made it 39 years without ever changing the oil in my car myself. But c'mon... how many people, when asked how much they like their new mid-sized car, will respond, "Oh, I love the drivetrain! It's flipping sweet! Wanna see it?"

My guess is JD Powers asked people to rate their cars along a standard set of dimensions, but didn't ask what dimensions actually mattered to them.

Explaining UX to 3rd graders


(object) (embed)

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.

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?

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 an[...]

Boxes & Arrows: Building the UX Dreamteam


There's an interesting article on B&A about Building the UX Dreamteam by Anthony Colfelt. Worth the read.

I've added my comments about the article on the B&A site, rather than here.

Explaining your products to your customers


This video illustrates some useful Best Practices from a UX standpoint.


(Thanks to my colleague Tim Francis for pointing me to this video)

Top 100 UX blogs - I demand a recount!


Virtual Hosting Blog has compiled a list of the Top 100 User-Centered Blogs. Shockingly, my blog did not make the list. This is an outrage!! I blame the hanging chads!! Stalin was right!!

Okay, so I only have one reader (Hi, Mom!), so maybe it's not a complete shock. (I'm just kidding -- my Mom doesn't actually read my blog)

Regardless, this is a really useful list of sites, and unfortunately highlights to me just how hard it is to keep up on everything that is going on.

Time to update my feeds.

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)

Outside-in Software Development


Carl Kessler and John Sweitzer (two IBMers) have written a new book called Outside-in Software Development. This book occupies an interesting spot in the UX-related book landscape. It's not really about design, exactly, nor is it prescribing a particular software process. It's written by an executive with experience on the management side of building software (Kessler) and an architect with experience on the technical side of building software (Sweitzer), and neither of them have ever been User Experience Professionals. And the target audience isn't UXers. I think it would be most useful for people in charge of software projects, including marketing, product management, managers, architects, and developers. I think UXers will enjoy it as well, but mostly because you'll find yourself nodding and saying "Damn right!" throughout the book - which is nice when reading a book written by a non-UXers. However, there are some ideas in the book that were new to me as well. One in particular that I liked is that the authors argue that when you build up your list of key stakeholders for a products (including end users and business sponsors), you should also include your internal stakeholders and their goals. This surfaces explicitly that sometimes internal stakeholders have goals that are in conflict with each other... and sometimes the end users. For example, developers are internal stakeholders and they usually have a clear goal of completing their code on time - which can lead to a conflict of interest. It's not a new thought that developers can have a conflict of interest, but it's a new thought (to me) that we should document that goal when defining a product's stakeholders. Get it out in the open. Talk about it. That's a really good idea.Mainly I found the book to be practical. Which is the highest form of praise for a book like this... and rare. It has fairly easy to implement ideas on how to shift towards outside-in thinking, and doesn't expect people to make a wholesale change to their processes in one fell swoop. They also discuss common mistakes (often with personal examples) and how to avoid them - such as trusting that your customers know what their own requirements are. And best of all (from my perspective), the book applies to enterprise software, not just building little websites. It doesn't assume that everyone on a project team is co-located and can fit in a single conference room with a whiteboard. Anyway, I recommend the book highly. (Full disclosure - in case anyone hasn't read my profile, I work at IBM too. I don't know Carl or John, but I've had one or two meetings with them over the years. I wasn't involved at all in the book - I didn't know anything about it until after it was published.)By the way, Carl also has a blog dedicated to Outside-in Thinking.[...]