The User Experience Soapbox

Tasks, Roles, Job Descriptions, and Personas

2010-08-04T10:39:00.002-04:00

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

2009-07-08T10:23:00.003-04:00

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

2009-06-29T21:18:00.002-04:00

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!

2009-06-26T07:36:00.002-04:00

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

2009-06-24T09:46:00.004-04:00

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

2009-06-17T13:38:00.002-04:00

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

2009-01-13T18:20:00.002-05:00

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!

2008-12-04T10:00:00.004-05:00

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

2008-11-22T07:41:00.004-05:00

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?

2008-11-20T15:06:00.005-05:00

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

2008-11-19T18:57:00.003-05:00

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 Target.com 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

2008-11-18T12:51:00.003-05:00

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 information whatsoever about what time it will be delivered."

The box never arrived on Wednesday.

We called back on Thursday and asked why it hadn't been delivered the day before. They said that someone had called and changed the address, but the address wasn't right so they sent it back to the warehouse.

I'm not making this up.

So they switched it back to the original (correct) address and said they'd send it back to us on Thursday. We asked again if it could be delivered urgently. They again said that they couldn't do that.

At 5:00 PM on Thursday the box still hadn't arrived. We called and changed it to Return to Sender.

No, it hasn't made it back to me yet.

At no point during this entire process did anyone from UPS do anything to actually help us. It was as if shipping something from one place to another in a timely fashion was not a core part of their business.

Here's what I can't figure out - how much money did UPS just lose? Obviously, I am never going to use their service again... for the rest of my life. This is not something I'm going to forget. So add up all the money I might have spent on UPS from here on out. How much would it have cost UPS to actually try to help me during this ordeal? Then, what is the difference between those two numbers?

I'm guessing tens of thousands of dollars.

Nice work, UPS.

Hmmm... that's a good question

2008-11-18T10:21:00.001-05:00

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

Helpless Desks

2008-08-07T09:58:00.003-04:00

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

2008-07-02T09:26:00.004-04:00

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-26T15:56:00.005-04:00

CNN.com 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

2008-05-30T13:43:00.004-04:00

| 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!

2008-05-06T14:22:00.003-04:00

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

2008-05-02T10:48:00.003-04:00

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?

2008-01-30T07:40:00.000-05:00

"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.

Boxes & Arrows: Building the UX Dreamteam

2007-11-30T14:05:00.000-05:00

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

2007-11-16T10:51:00.000-05:00

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!

2007-11-09T08:28:00.000-05:00

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

2007-11-09T07:36:00.000-05:00

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

2007-11-02T08:38:00.000-04:00

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.

User experience practitioner roles

2007-10-29T09:59:00.001-04:00

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?

In my best Arnold voice... "I'll be back"

2007-10-11T06:31:00.000-04:00

Thanks to some international travel, a nasty flu bug, and transitioning into a new job, I've been completely buried the last few weeks. I haven't even had time to watch all of my "Jekyll" DVD, much less blog.

I'm starting to see the light at the end of the tunnel now, so I should be back to my regular blogging routine soon. I feel completely out of the loop because I've missed so many new blog posts in my blog reader... I'm a little panicky about it... I wonder if that's healthy?

A few pictures from London

2007-10-01T11:29:00.000-04:00

I went to London for a couple days at the end of last week for a customer visit. My first time in London, but unfortunately the quick turnaround didn't leave much time for sightseeing. Here's a couple of my favorites pictures that I snapped:

The Economist discusses user experience

2007-09-11T09:05:00.000-04:00

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

2007-09-11T08:48:00.000-04:00

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..." )

Are bad personas better than no personas?

2007-09-07T10:12:00.001-04:00

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

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

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

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

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

Complex is better than simplistic

2007-08-29T12:29:00.000-04:00

Courtesy of Joe Lamantia, I found Dan Ward's "The Simplicity Cycle". It's a quick read, it's free, and it's insightful... all good things. It basically centers around the graph to the right, which represents a product lifecycle.

The idea is that you start in the lower left hand corner, which is "simplistic" in the sense that it's simple because it doesn't do much. As new features get added, complexity increases but so does "goodness" because the user can do more stuff.

But then at some point you reach the middle of the graph and things get interesting. It's basically the complexity "tipping point", because now when you add more stuff (a.k.a. complexity), goodness starts to go down because users are unable to consume the additional complexity. The only way to increase goodness at this point is to decrease complexity.

That's the gist. I recommend reading the whole thing to get the details.

I like this for a couple reasons. First is that it suggests that complexity is not inherently bad. I couldn't agree more with this. Designers who think "simplicity" is the goal of design live in a different world than I do. I also like that Ward uses the term "unnecessary complexity", which is a favorite phrase of mine. Just because complexity isn't inherently bad doesn't mean that there isn't plenty of unnecessary complexity in most software.

I also like that it helps answer the question, "Hey, my product is complex AND successful, so why should I worry about design?" There's a limit to how many features you can add to a product before they become self-defeating. When your customers start to request features that are already in your product, it's a safe bet that adding even more features is going to be trouble.

So I think the graph represents a very useful concept, and makes it easy to understand.

Of course, like most concepts, if we starting poking on it we can find limitations. For example:

Most products have problems with unnecessary complexity, and that is NOT what the complexity axis is measuring - but I would fear someone walking away from the graph thinking that complexity in general is not something to worry about until you get to the middle of the graph.
Ward points out that reaching the bottom right of the graph is not the end of the story. The curve just starts back up again. But in reality, what happens is that different parts of a product are probably following their own paths - some in simplify mode and some in add feature mode, so a single line doesn't really represent a whole product.
The place where complexity becomes too much is different for different users (and sometimes radically different). So the graph is really representing the perspective of one user group.

But these are just nits, because I think Ward's goal was to use the graph to present the concept, not to create a formal process or an accurate depiction of every variation under the sun. And it does a good job at that... the concept is useful and the book introduces it quickly and easily.

iPhone user experience presentation

2007-08-27T09:08:00.000-04:00

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.

UX Roadblock #17: Development tools and frameworks

2007-08-20T10:35:00.000-04:00

In every software release, there are always resource constraints. It's an immutable fact of life, like the sun rising in the east or your toast falling butter side down. There's not a lot of value in complaining about it... and pretending that your work should be done without regard to resource constraints or ship dates will lower your credibility.

However, even if we accept that resource constraints are a fact of life, it still can be the case that these constraints are inappropriately impacting the user experience. In other words, resource constraints are an issue for everyone in every discipline, but sometimes the impact on one area is out of whack with what other areas are facing. One way in which this can happen to user experience is via bad development tooling and frameworks.

Development tools and frameworks are intended to make developers more productive. When done poorly, they can create a situation where developers are more productive if they follow a single path, but any deviation from that path results in a huge development effort. And deviating from that path is often requested by the UX team. This can result in mind-boggling conversations like, "Sorry, I can't change the label on that button... the framework is giving me the label, and I would need to custom code the entire page to change it." The trick is to recognize when a developer is feeding you a line of crap to avoid extra work versus when there really is a tools/framework issue. Or both!

As an aside, one area where I've repeatedly seen this issue is in the area of product installation tooling. These try to make things easier by giving the developers a bunch of common install functions for free. But it's often an all or nothing proposition... you either use the common function EXACTLY or you have to start from scratch. So there's a resource cliff. A minor design change creates a huge impact on the development sizing. So as a designer you get stuck with accepting a bunch of minor irritating behaviors because none of them individually are worth throwing out the free behavior.

As with most roadblocks, we UXers often have to live with them rather than remove them. Removing the roadblock in this case obviously means choosing new tools or creating better frameworks. Sounds good, and worth fighting for, but that doesn't happen overnight. In the meantime, what can we do to detour around the roadblock? Here's my advice:

Learn everything you can about the tools and framework so that you know exactly when you are designing something that will force extra effort. Don't rely on the developers to tell you.
Only design "outside the framework" when it matters. This builds on #1. If you ignore the framework when doing the design, you'll run into situations where you are deviating from the framework randomly, out of ignorance, which causes unnecessary battles with development or forces developers to spend their time on things you don't really care about. When you deviate from the framework, make it count.
Build an expectation into the development sizing effort that deviating from the framework is normal. This builds on #1 and #2 - they give you credibility so developers know that you aren't being a hardass for no reason. You want to avoid a situation where any deviation from the framework is considered "extra" work that needs to be separately contained. Assume there will be some deviation upfront, and size accordingly. This is also the key to removing the roadblock altogether - the cost of sticking to the framework needs to be exposed via the sizings.

When good design means bad usability

2007-08-17T09:43:00.000-04:00

I ran into an interesting usability issue recently. I was trying to cancel some magazine subscriptions through the Magazine Service Center. The Magazine Service Center is basically a scam, though a legal one. Their business model is basically to give people free subscriptions to magazines, then automatically start charging for them after a year has passed, and make it as difficult as possible to cancel them.

When you call them to cancel (which of course can't be done online), you are never given the option to speak to a human. After navigating through the list of options to get to the cancellation prompts, they won't give you a list of magazines that you are currently subscribed to. You have to say what magazine you want to cancel, then they repeat it back to you, but the response comes back garbled so that you're not sure whether it's right. I said, "National Geographic Explorer" and they responded, "You said, 'Fghwhpfft', press one if that is correct". I tried this several times with the same unintelligible response before just assuming they'd figure it out and moving on.

Then the fun really starts. They say they want to "confirm" you decision to cancel. They say that you still have a few weeks left on your subscriptions. There's a fee for canceling. If you don't cancel now, they'll waive the fee. And they ask you to confirm that you want the fee canceled. In other words, to confirm that you want the magazine canceled, you have to respond "NO". When you select "No", they go through it again, to "make sure they understand", and you once again need to select "No" to confirm the cancellation of Fghwhpfft.

So the question is: Is this bad design? It's completely unusable. But it's completely unusable on purpose. It's completely unusable in order to meet their business goals. And, to be honest, it's unusable in clever ways, not by accident. Someone spent a fair amount of time and thought to design the system in a way that maximized the user's failure rate.

Of course, this brings up ethical issues. I doubt many UXers have to make these types of decisions - choosing between good usability and good business. Fortunately, the two are almost always aligned. But in subtle ways, I think it does appear. Such as how easy should it be to migrate from your product to another vendor's product? Users want to avoid vendor lock. Business goals don't always agree.

I'm trying to think of other examples, but I'm drawing a blank.

I've been out of grad school for 12 years....

2007-08-17T08:39:00.000-04:00

... and out of undergrad for 17 years.

So isn't it about time that I stopped having these "Omigosh! The final exam is today and I forgot to attend class all semester!" stress dreams? My subconscious is stuck in the early '90s.

Maybe if I updated my music collection with some post-1995 tunes it would help.

Nah, too risky.

Life without mouse clicking

2007-08-14T13:54:00.000-04:00

A colleague forwarded this link to me - http://www.dontclick.it/

It's a browser interface that completely removes the need to click the mouse button.

I'm not sure that there's a problem worth solving here, but it's an interesting exercise.

Unsuccessfully buying a laptop at Best Buy

2007-08-11T14:30:00.000-04:00

My wife needs a new laptop. We went to Best Buy. We found the laptop we wanted, with all the right stuff on it, at a price that we felt was reasonable. Just one minor issue. Like most laptops, this one idiotically had 1 Gig of RAM to run Vista Home Premium, so we needed to upgrade it to 2 Gig.

Me: "How much is a Gig of RAM for this laptop?"

Best Buy Employee: "About $120."

Me: "Sounds good. We'd like to get this laptop, but we want to upgrade from 1 Gig to 2 Gig."

BBE: "Okay, that'll be an extra $240."

(pause)

Me: "Uh, sorry... I just need 1 extra Gig of memory. That's $120."

BBE: "No, the laptop has 2 memory slots. Right now it has two 512MB memory cards in them, so you'll need to buy two 1 Gig memory cards to get to 2 Gig."

Me: "Riiiight... but I don't need the two 512s, which cost $120, so it's still only a $120 difference."

BBE: "No, you're buying the laptop as is, so the two 512s are your's, and to upgrade you need to buy the two 1 Gigs for $240."

Me: "And then I just throw away the two 512s?"

BBE: *shrugs*

Me: "You do understand that you've just lost this sale, right?"

BBE: *shrugs*

Always one year removed from incompetence

2007-08-09T18:55:00.000-04:00

As my wife will happily tell you, I have many, many faults. For example, I am incapable of finding the ketchup in the refrigerator. My wife can talk on the phone, make a craft, help the kids with their homework, and watch Oprah at the same time... I can watch a bad movie for two hours and not notice the house is on fire. My fashion sense has not changed or improved since I discovered jeans and t-shirts in second grade.

And I consistently hold my own opinion in higher regard than it deserves.

On the bright side, I eventually recognize that I was an idiot... it just takes about a year. Then I look back in horror at how incompetent I was. This became a yearly rite of passage for me - marveling at my newfound wisdom compared to the previous year. It was nicely validating for awhile, until I started looking ahead and wondering what I was doing now that I'd be embarrassed about next year. Takes all the fun out of feeling superior to... er, myself.

Looking back over my learning curve to date, one thing that strikes me is that in addition to simply learning through mistakes and casual chaos, I've always worked with a team of user experience professionals, and they are the ones who have helped me grow into the proud, just-beyond-incompetent UXer that I am today. I don't think you can overestimate how important that is - UXers who are isolated on development teams are almost doomed to stagnation, IMO. For those folks, the only way to avoid this fate is the virtual UX team on the internet. Bravo to all the UXers who make the net a vibrant community from which to learn.

Which brings me back to my original point - what am I going to learn over the next year that is going to make me feel incompetent now? I'm not sure (if I knew, I'd just go ahead and learn it now), but it's very likely that I'll learn it from someone on the internet. Not in one place on one day... in a hundred blog posts and comments and articles and research, all providing a tiny piece of the puzzle leading to the next minor epiphany.

I'm looking forward to it. In the meantime, I'll just have to make do with what I've learned so far. And ask my wife to find the ketchup for me.

UX Roadblock #48: Sexy Requirements

2007-08-05T13:50:00.000-04:00

There are a thousand different ways to manage requirements and plan a release. One of the all too common methods is to make a list of the biggest, most important requirements and rank them from top to bottom based on "customer need". Of course, "customer need" can mean anything from "an executive already promised this to a customer" to "marketing thinks this feature will enable us to get into a new market". If you've been on a team that used this method, you know what happens... people learn that the best way to get your favorite requirement into the product is to make it as big and sexy as possible. Because once you have the ranked list, sizings are done and once the resources run out you've got your list of in-plan requirements. If your requirement isn't near the top, now matter how easy it is to do or how great the ROI is, it won't make it in.

This is a bad method for lots of reasons, but it particularly hurts the user experience. First, the overall user experience is made up of a ton of small interactions, and often the best way to make improvements is to fix a lot of small issues rather than add some groovy new "user experience feature" while leaving the small issues alone. Those small issues add up quickly. But comparing any of the small fixes to one of the big sexy requirements makes the small fix look optional.

Second, this type of process encourages a "feature-centric" view of release planning. The discussion naturally becomes focused on which of two features is the most important... and tends to avoid the discussion of whether either feature is the best way to spend those resources. Making the existing features better gets lost in the mix.

If you are stuck in this situation, you might not have the ability to force a wholesale change to the process (which is what is ultimately needed). If that's the case, here's some pragmatic advice on how to get around this particular roadblock (based on my own experiences):

Create a big sexy requirement that is a collection of UX improvements and try to tie the individual improvements into a single theme that will sound good to release management, like "Decrease customer time-to-value through out-of-box-experience improvements". Of course, you'll know that this is really just a bunch of little improvements, but by combining them together by theme you'll be able to better compete against the new feature requirements.
Work with release management (and product management) to create "buckets" of resources that are dedicated to particular release objectives, then prioritize within the buckets. And, of course, make sure one of the buckets is dedicated to user experience. This is easier than it sounds because (almost) no one thinks user experience is unimportant, and at a theoretical level it's easy to convince folks that some percentage of effort in a release should go towards improving the user experience... the problems arrive when those well-meaning people are forced to choose between a new feature that some customers genuinely want and improving the user experience. By creating separate buckets, it removes that forced choice.
Partner with the folks who are working on one of the big sexy new features that is likely to make it into plan and persuade them that there are a number of user experience improvements that ought to be tied to the requirement. One reason this technique can be so successful is that adding user experience items to the new feature can make it even more sexy, so the people pushing the new feature are motivated to work with you. The downside to this is that unlike the first two techniques, tying the UX improvements to a new feature constrains your choice of which UX improvements to tackle. You have to pick things that relate to the new feature, however loosely. Of course, if your choice is between getting nothing done versus getting your second or third choice done, it's still an easy decision.

None of these actually removes the roadblock, they just help you get around it.

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

2007-08-03T09:14:00.000-04:00

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.

Supporting browser back buttons in web apps

2007-08-01T12:38:00.000-04:00

Simple question. If I'm using a wizard in a web application (and the wizard has a Back button) and I click the browser's Back button instead of the Back button supplied by the web application, should the behavior be the identical?

Simple question, but the answer? Ugh.

There's a lot of discussion on this topic on the web, but interestingly the focus of much of the discussion is how to get users to stop using the Back button. Whether it be by providing them with back buttons in the app, adding breadcrumbs, or disabling the back button altogether. This strikes me as quite an odd solution to the problem.

At the same time, there are times when the back button is clearly inappropriate. If I have just finished clicking "Finish" in a wizard and I'm taken to a "Okay, here's what just happened" page, clicking the browser's back button is not a good thing.

But if the web app itself supports a Back button, why should it not also support the browser's Back button? And, if you agree with that, let me ask the next question. Should you be able to click the browser's Forward button and have it work like the "Next" button in the wizard?

My head hurts.

Managing Experience: Adaptive Path nails it

2007-07-27T14:17:00.000-04:00

The folks at Adaptive Path recently announced their 2nd "MX conference", which focuses on, basically, how to actually get things done. In the announcement, they say:

The unsung heroes are those folks who shepherd projects through an organization, demonstrating the value of an experience design approach, ensuring that their product maintains quality in the face of competing priorities. Such shepherding is hard, but is necessary for design to succeed.
This is why we created the MX Conference. MX stands for Managing Experience. It exists to fill the void between the practical discussions craft, and the hand-wavey discussions of The Power Of Design. The event is focused on helping people understand what it takes to get great experiences out into the world, in the process building a community of folks addressing similar challenges.

Bravo! On this blog, I've touched on this topic a couple times (like here, here, and here). Basically I feel a sense of frustration that more thought and effort isn't spent on what I would consider to be the core issue that faces most user experience professionals - how difficult it is to get improvements into a product. We spend a lot of time talking about how to create a good design, and we do a lot of chest-thumping about how important good design is, but as the post above notes, there's a large void between these two.

Don't get me wrong. I think good design is hard. I think it's reasonable that this is a major topic of conversation. I think as a profession we still have plenty to learn in this space. In addition, I think it's obvious that we've got a long way to go in changing the default IT culture so that the importance of experience design is a foregone assumption - so some chest-thumping is warranted.

But in some sense those are the easy problems to solve. I am guessing there are lots of places that fit each of the following three criteria:

1. They have quality user experience professionals on staff

2. They have an organization that understands the importance of experience design

3. Getting actual improvements into the product requires navigating around 100 roadblocks and an Act of God

I think the reason more time isn't spent on this subject is that it's uncomfortably murky. The roadblocks aren't the same from organization to organization. It's not always clear who in an organization should be the shepherd. And, to be honest, I think there are user experience folks who feel that their job is to create quality design... and if that design doesn't make it into the product, they've still done their job.

But personally, I think a lot of the roadblocks are common (though not universal), and it would be good for the UX community to discuss techniques for getting around them. It won't be a one size fits all solution, but I think we have a lot to learn from each other here.

UIE: Interview with Scott Berkun

2007-07-26T14:13:00.000-04:00

UIE has posted a short interview with Scott Berkun, author of The Myths of Innovation, which I have reviewed previously.

The best part of the interview is Berkun's response when asked whether there are situations when teams should NOT focus on innovation. Berkun replies:

Yes! Thanks for asking! I think innovation is overrated. Customers don't care about how innovative you are. They just want to be happy and satisfied. And that's about good design.
The best advice I can give is to focus on people and their problems. Few great innovators worried about anything else. The fact that they found a new idea had more to do with their passion for solving someone's problem than anything else. Innovation is a huge distraction these days. That's one of the myths I hope people will understand how to dispel from reading the book or attending my seminars.

I thought this was great, because I've always felt there was something hokey when companies encourage innovation for the sake of innovation. Who cares about innovation if the innovation is useless? The trick is create a culture in which problems that don't seem to have an existing solution are seen as opportunities for innovation, rather than dead ends. It's all about problem solving.

Via Croc o' Lyle: If architects had to work like programmers

2007-07-25T09:01:00.000-04:00

Croc o' Lyle points us to a great faux letter that was apparently created by Software Technology Support Center. The letter is a PDF, but I've cut-n-pasted it here for your reading convenience:

Dear Mr. Architect:
Please design and build me a house. I am not quite sure what I need, so let’s get started. My house should have between two and 45 bedrooms. Just make sure the plans are such that the bedrooms can be easily added or deleted. When you bring the blueprints to me, I’ll make the final decision about what I want. Also, bring me the cost breakdowns for each configuration so I can arbitrarily pick one at a later time.

Keep in mind that the house I ultimately choose must cost less than the one I am currently living in. Make sure, however, that you correct all the deficiencies that exist in my current house (the floor of my kitchen vibrates when I walk across it, and the walls don’t have nearly enough insulation in them).

As you design, also keep in mind that I want to keep yearly maintenance costs as low as possible. This should mean the incorporation of extra-cost features like insulated windows or composite siding. (If you choose not to use Anderson insulated windows, be prepared to explain you decision.)

Please take care that modern design practices and the latest materials are used in construction of the house, as I want it to be a showplace for the most up-to-date ideas and methods. Be alerted, however, that the kitchen should accommodate (among other things) my 1952 Gibson refrigerator.

To assure that you are building the correct house for our entire family, you will need to contact each of my children and our in-laws. My mother-in-law will have very strong feelings about how the house should be designed, since she visits us at least once a year. Make sure you weigh all these options carefully and make recommendations. However, I retain the right to overrule any recommendation you make.

Please don’t bother me with small details right now. Your job is to develop the overall plans for the house and get the big picture. At this time, for example, it is not appropriate to be choosing the color of the carpeting; however, keep in mind that my wife likes blue.

Also, do not worry at this time about acquiring the resources to build the house itself. Your first priority is to develop detailed plans and specifications. Once I approve these plans, however, I would expect the house to be under roof within 48 hours.

While you are designing this house specifically for me, keep in mind that sooner or later I will have to sell it to someone else. It should — therefore appeal to a wide variety of potential buyers. Please make sure, before you finalize the plans, that there is a consensus of the potential home buyers in my area that they like the features of this house.

I advise you to run up and look at the house my neighbor built last year, as we like it a great deal. It has many things that we feel we need in our new home, particularly the 75-foot swimming pool. With careful engineering, I believe you can design this into our new house without impacting the construction cost.

Please prepare a complete set of blueprints. It is not necessary at this time to do the real design, since they will be used only for construction bids. Be advised, however, that you will be held accountable for any increase of construction cost as a result of later design changes.

You must be thrilled to be working on such an interesting project! To be able to use the latest techniques and materials and to be given such freedom in your designs is something that can’t happen very often. Contact me as soon as possible with your ideas and completed plans.

Sincerely,
The Client

PS: My wife just told me she disagrees with many of the instructions I have given you in this letter. As the architect, it is your responsibility to resolve these differences. I have tried in the past and have failed to accomplish this. If you can’t handle this responsibility, I will have to find another architect.

PPS: Perhaps what I need is not a house at all, but a travel trailer. Please advise me as soon as possible if this is the case.

I think the part about the 1952 Gibson refrigerator is my favorite.

Todd Wilkens: Why usability is a path to failure

2007-07-18T12:19:00.000-04:00

Todd Wilkens of Adaptive Path expressed some frustration about usability:

When talking of a great writer, how often do people talk about how amazingly legible they are? When talking about a great photographer, does anyone ever talk about the fact that his prints actually developed and thus are visible? Obviously, the answer is no. Legibility and visibility are the bare minimum of requirements for a successful piece of writing or a photograph. Any person who focused most of their efforts on legibility or visibility would probably have almost no chance of being a successful artist. Something that is fundamental to great creative acts is aiming high. If your goals and strategies are not oriented toward excellence then it is highly unlikely that your tactics will get you there. No one tells their kids to aim for a C- and then expects them to get an A.

So, why oh why do people in this day age still hold up “usability” as something laudable in product and service design? Praising usability is like giving me a gold star for remembering that I have to put each leg in a *different* place in my pants to put them on. (Admittedly, I *do* give my 2 year old daughter a gold star for this but then she’s 2.) Usability is not a strategy for design success. The efficiency you create in your interface will be copied almost instantaneously by your competitors. Recently, I’m even coming to believe that focusing on usability is actually a path to failure. Usability is too low level, too focused on minutia. It can’t compel people to be interested in interacting with your product or service. It can’t make you compelling or really differentiate you from other organizations. Or put another way, there’s only so far you can get by streamlining the shopping cart on your website.

Obviously this can lead to a religious terminology war, but for the purpose of this post I'm going to assume that Todd defines usability as "making sure that users can complete their tasks with a reasonably low failure rate"... and nothing else. Of course, I agree with Todd that this is just the beginning of designing a quality product, but I think perhaps he's not giving usability enough credit. Here's why:

1. I think it's nearly impossible for an organization to successfully focus on other aspects of experience without first becoming (at least) competent in basic usability. It's a step that can't be skipped, for all practical purposes. So an organization that went from nothing to doing basic usability should be praised for making progress, because they couldn't have chosen to go beyond basic usability in step one anyway.

2. Great artists break the rules... but great artists know the rules. If an artist creates a masterpiece by breaking rules that the artist didn't know about, it isn't genius, it's luck. In some sense, basic usability means "knowing the rules". For example, whenever we talk about the value of consistency in my job, I always make the point - it's okay to not be consistent, as long as the inconsistency isn't done out of ignorance, but by design. Usability is the foundation for everything else.

3. And last but not least... usability is HARD. Look around. We're surrounded by unusable crap. (I was editing a wiki page today and my username timed out while I was editing, so when I tried to save, it prompted me for my id and password, then took me back to the wiki homepage and threw away my work!) There are many, many roadblocks to creating a product that is usable in even the most basic sense. Kudos to the ones that achieve it. Is it enough? No, but for most teams it's a praiseworthy first step.

Post-vacation roundup

2007-07-17T08:46:00.000-04:00

After a long weekend of taking my son to the Smithsonian Institute for his 9th birthday, here's a few of the things I missed while I was out:

Adam Polansky has an article on Boxes and Arrows about "Faceted Feature Analysis", which is basically a way to prioritize feature requirements in a way that takes ego out of the mix.
A discussion of Charlie Card usability problems at Compete on Usability - as if we don't have enough problems getting people to use mass transit in this country.
Bokardo has a discussion on why the Netflix site is so good - which I agree with completely. I've been sticking with Netflix for longer than I probably should because a) Blockbuster is evil, and b) I love the Netflix app.
Jeffrey Veen tells an interesting tale of how design inspiration can come from strange places - like Raiders of the Lost Ark - and why you should sleep with your laptop.

Kudos to Yahoo! Photos

2007-07-09T09:53:00.000-04:00

Yahoo! Photos is closing. I got an email from them over the weekend. Here's a section of it:

We will officially close Yahoo! Photos on Thursday, September 20, 2007, at 9 p.m. PDT. Until then, we are offering you the opportunity to move to another photo sharing service (Flickr, KODAK Gallery, Shutterfly, Snapfish, or Photobucket), download your original-resolution photos back to your computer, or buy an archive CD from our featured partner (for users of the New Yahoo! Photos only). All you need to do is tell us what to do with your photos before we close, after which any photos remaining on Yahoo! Photos will be deleted and no longer accessible.

Of course, we hope you'll join us at Flickr (you can even use your Yahoo! ID), but we also realize that Flickr may not be for everyone. In the end, we want you to find the service that's right for you, and we hope you take some time to learn more about your options before making this important decision.

That's an exceptional marketing move - give people the option of automatically migrating to a non-Yahoo!-owned photo service. Forcing everyone to migrate to Flickr would have been the easy thing to do, but this is smarter. People like choices, and there will be people who are angry that Yahoo! Photos is shutting down and forcing them to change services. By giving them a choice of services for migration, Yahoo! gets their Miracle on 34th Street moment instead of bad press.

Nicely done.

Nielson: bad blogs

2007-07-09T09:35:00.000-04:00

Nielson on good articles, shallow blogs. Me no likey. Think Nielson misses point. Will write more after I find my crayons.

The little deviants

2007-07-09T07:15:00.000-04:00

I took the kids to see Fantastic Four: Rise of the Silver Surfer yesterday. In the commercials before the movie, there was this:

So the commercial has demons living in the sewers who emerge to attack the "sheeple". The demons decapitate the sheeple, play with the decapitated heads, slip into the skin of the sheeple, and, apparently, customize their cars. The demons are the good guys in the commercial. My 8-year old son had nightmares last night from that commercial... seriously. And the worst part is, I bet Scion would be happy to hear that. This reminded me of another recent commercial, where a cellphone company was trying to sell a new feature that, I guess, allows to text message multiple friends at a time. What should you do with this feature? Apparently arrange so that you and your friends can all simultaneously vandalize a grocery store. Again, the people doing the vandalizing are the good guys in the commercial. The target audience. This is not trend I'm happy about.

Compare that to this Liberty Mutual commercial:

How do you want your company to advertise?

UIE: "Ten Ways to Kill Good Design" by Kim Goodwin

2007-07-03T12:05:00.000-04:00

UIE has an excellent article from Kim Goodwin called, "Ten Ways to Kill Good Design". I don't have much to add, other than, "Yeah, what she said!" In particular, she nails one of my pet peeves - developers making business decisions. She says:

When we say the inmates are running the asylum, it means the programmers are making business decisions that should be made by executives. In most cases it's not intentional, and the majority of people are unaware of the extent to which it happens. However, every time a programmer says "That's not technically feasible," he's just made a business decision that's invisible to most people, since "not technically feasible" really means "not in the tiny amount of time or with the constraints I know you're going to give me."

I have an enormous amount of empathy for developers. They often have unreasonably huge amounts of work to do and unreasonably tiny amounts of time to do it in. But when a requirement is in plan and then the developer guts half the requirement by saying "no" to designing it well, that's a business decision that needs to be made somewhere else.

Speedbird: "Lessons from experience design"

2007-06-29T08:21:00.000-04:00

File this one under "Damn! I wish I was smart enough to have written this!" - Adam Greenfield has a great blog about experience design on Speedbird. This opus makes me look pithy, but it's worth reading the whole thing.

The clear intention was to ensure that the customer interaction inscribed in each of these phases was designed to the same high standards as an IDEO mouse or shopping cart. But with the best of intentions, this way of thinking led Acela into error.
The assumptions embedded in the plan are too tightly coupled to one another. They feed from one to the next - remember the word - seamlessly, like brittle airline timetables so tightly scheduled that a delay anywhere in the densely-interwoven mesh of connections cascades through the entire system. When it all succeeds, it’s magnificent, but if any aspect of it fails, the whole thing falls apart.

I could almost hear the clicking sound when several ideas bouncing around my head fell into place as I read this.

Functioning Form: "Design for the Edges"

2007-06-27T06:43:00.000-04:00

Functioning Form has a new entry about Design for the Edges: Managing Edge Cases. This is a fascinating topic for me, because in my opinion this is one of the core ways in which designing "enterprise software" differs from designing "consumer software". Enterprise software is not about achieving ubiquity, it's not about being "good enough", it's about satisfying the often very complex requirements for enterprises beyond what the "good enough" products can do. The edge cases aren't something to avoid... they are the core value proposition of the software. For example, Jamie Hoover in the article advises "Make your software as simple as possible. Less complexity decreases the possibility of edge cases in the first place." While this is obviously good advice in general, when it comes to most enterprise software, this is not useful whatsoever. The complexity of the system into which the enterprise software is plugging already exists. That complexity is the source of the requirements. By making the software "simpler", we'd simply be reducing the number of systems in which our software would be useful.

It's unfortunate that so much of our attention as designers has been focused on ways to simplify our own jobs to reduce the complexity of design problem by using techniques that try to find commonality across roles and scenarios... which makes our lives easier but oftentimes does not help our end users, who experience a much richer life that the one we've forced upon them.

A List Apart: "Testability Costs Too Much"

2007-06-26T09:30:00.000-04:00

Gian Sampson-Wild has penned a deliciously provocative article at A List Apart titled "Testability Costs Too Much." It is specifically about accessibility and the W3C, and asks the question - is it possible to have a good guideline that isn't testable? Sampson-Wild emphatically argues "yes". It's definitely worth a read.

But what got me thinking is how often this same question is brought up outside of the accessibility domain. Specifically, I've dealt with this in both setting usability objectives and when creating design guidelines.

It goes without saying that setting usability objectives for a product or a release is a good thing, right? I'm not convinced. Usability objectives can do as much harm as good. First, who decides whether the objectives are met? And how do they decide? Is it useful to have an objective that "The product will be easier to use than the previous release"? Probably not. But what if we operationally define the objective as "User satisfaction will increase from 3.2 to 4.0"? That seems testable. But if that is a release objective then it needs to be tested before the release is shipped. That means a late-cycle design validation. That means creating meaningful, representative scenarios for users to perform (often in a lab setting). And do you test the new features or do you use the same scenarios as the previous release to have an apples-to-apples comparison? if you just test the new stuff, is that valid? If you just test the previous samples, are you really testing the new release? How does it cost in time and resources to conduct the testing? If the objectives aren't met, do you delay the release? How much resource do you need to apply before you've got enough testing data to make a delay-the-release decision? Is it worth it?

Another option is to set objectives that don't require user testing. For example, you can use quantitative measures of user experience like step counts. An objective might be, "Completing this task will go from 27 steps to 10 steps." But this has a lot of problems as well. First, defining a "step" is easier than it sounds. Second, defining a "task" is easier than it sounds. Third, and I think most importantly, reducing the number of steps does NOT mean the task is more usable. You can improve usability by reducing steps, but it's not a guarantee. These quantitative measures of user experience are almost always secondary effects, which can lead to all kinds of problems. And in the end, these objectives still need to be "tested", usually by UXers, and although it is cheaper than user testing, there's still a ROI problem.

Compare this to just having a smart UXer on your team that you trust, and ask her "Do you think we've done what we intended to do in this release from a usability perspective?" Very high ROI.

Usability objective testing costs too much.

Now what about design guidelines? In this case, the "test" relates closely to Sampson-Wild's description "reliably human testable—which means that eight out of ten human testers must agree on whether the site passes or fails each success criterion." Now I'm going to extend this slightly to make it harder... a design guideline is testable if eight out of ten developers agree on whether guideline has been met. In many cases, guidelines are used because UXers don't have the resources to design everything in the product, and developers forced into design work need guidelines to help them make decisions. Of course, for UXers every guideline is "It depends". "It depends" is not a good guideline to give to developers. But damn it, design is HARD and the Truth is that the right answer really does depend on a bunch of factors that don't lend themselves to pithy guidelines that a non-professional-designer can consume and understand at a shallow level.

But if your developers are doing design anyway, then that's just tilting at windmills. Dumbing down your guidelines so that they are testable by developers is the right thing to do. In this case, I think the cost of making it testable is worth it. Coming up with guidelines that require expert interpretation when you know non-experts need to follow the guidelines is not useful, it's arrogance.

Book review: "Small is the New Big" by Seth Godin

2007-06-25T07:16:00.000-04:00

The first question is, why would anyone by a book that is actually a compilation of blog posts? Blog posts that are still available for free online for anyone who wants to read them. To answer that, a little background is in order.

Seth Godin is one of the new marketing gurus of the internet age, and runs an extremely popular blog (aptly titled Seth's Blog), as well as being the author is several books that extol the virtues of permission marketing and innovation. But pigeon-holing Godin as a marketer doesn't really tell the whole story. Godin is part marketer, part guru, part motivational speaker, part pundit, part critic... basically he has a strong belief in his own opinions, loves to share them, and enough people find enough of them to be insightful that an entire Seth Godin cottage industry has sprung up around them.

Since a colleague of mine pointed me to his blog awhile back, I read pretty much everything he posts. What I find most interesting is that I only find value in maybe half of what he says. Another 25% is what I would consider to be "motivational speaker crap". And the other 25% I simply disagree with. But holy cow, there's just so much of it, that even a 50% hit rate produces a lot of quality content. His book is the same way (not surprisingly, since it is from his blog originally). So why did I buy "Small is the New Big"? Basically, it was my way of supporting Seth's blog. It provided me a simple way of reading his archived blog entries in handy book form (for example, I could take it along to the pool during my kid's swim class), but mostly I just felt Godin had earned it.

Fortunately for Godin, I bought it online, because if I had picked the book up and turned it over and read, "you're smarter than they think" in big text at the top of the back cover I probably would not have been able to face the cashier at Barnes and Noble. Outside of Stuart Smalley, that's the kind of motivational speaker crap for which I have a very small tolerance. But here's the thing: I think Godin expects exactly this kind of reaction. In his introduction to the book, he says:

I guarantee you'll find some [blog entries] that don't work for you. But I'm certain that you're smart enough to recognize the stuff you've always wanted to do buried deep inside one of these riffs. And I'm betting that once you're inspired you'll actually make something happen.

Why is Godin convinced that I'm smart enough (and doggone it, people like me)? Apparently because I was smart enough to buy his book. But more importantly, Godin knows that his hit rate isn't 100%. He's fine with that. He's fine with being all over the map. But I'm also guessing that the parts that I like are not the same parts that another person would like. It's about taste, not about being right and wrong. He also hits on another point, and to his credit he's self-aware enough to recognize it - many of his posts say what people already know, but there's value in being reminded of it. Reading the book, I repeatedly had the reaction, "Yeah, that's true, I knew that... I wonder how I can apply that?"

The best thing about Godin is he makes you think. He has a knack for speaking in just enough generality that most of what he says feels applicable to your job, while not being so general that it's not useful. Even he act of disagreeing with him (like my disagreement with most of his riff on website design) is useful because disagreement requires thought. And he's engaging enough that even disagreement feels friendly and personable. I get the feel that I could have lunch with him and we could argue the entire time... and yet we'd both leave the meal having enjoyed ourselves with no hard feelings.

I recommend the book. You won't like all of it, but I bet by the time you finish it you'll feel it was time well spent.

From UPA: The Future of Usability

2007-06-21T08:27:00.000-04:00

A colleague sent me a link to the proceedings for the latest UPA conference that was held in Austin, Texas last week. One of the items was a panel discussion entitled, "Looking in the Crystal Ball: Future of Usability". I particularly enjoyed the charts by Daniel Szuc from Apogee. One of his charts asks the question, "Who/What do we want to be?" followed by these bullets:

User Tester v Designer (or both)
Closer (issues) v Opener (innovations)
Loner v Collaborator
Critic v Creator
Silo v holistic

Good questions, because other than the third bullet, the answers are not clear. Well, I have clear opinions on each one, but as an industry the answers are not clear. For example, the last question might seem obvious... but one of the panel speakers (Robert Schumacher from User Centric, Inc.) warned about the danger of diversity and the cheapening of our skills by being a blend of so many different disciplines, while advocating for the need for a clear UX certification process to separate the real professionals from the, um, amateurs. Basically, Schumacher wants to create more crisply defined UX roles because he believes that the "holistic" blending of our field with every field we come into contact with cheapens our value. He has a valid point, though I think it's a bit like trying to prop up local shops by legislating against Wal-Mart - it might be a noble goal, but it's ultimately useless because it fights against reality. We need to make things work in spite of the blending of roles, because the there is no other alternative, IMO.

Anyway, in the spirit of the exercise, here's a few of my thoughts on the future of usability, in easy-to-read bullet form:

In the category of "Well, duh!", specialization within the field will increase. One specialization that I think will emerge into a common category is the "Designer Developer" - not a developer who learns some design skills, but a UXer who learns some development skills.
Focus on user testing will decrease over time.
The importance of patterns and particularly patterns-enabled development tools (basically 4GL GUI tooling) will increase. Creating good design is too hard today... there will be a lot of incentives in the near future to make good design easier to implement.
There's going to be a lot of drama in the community in the near future as gurus begin to really differentiate... and think the other gurus are full of crap. And say it out loud. I think it'll be a good thing for our profession, but it'll be ugly while it happens.
Returning to the "Well, duh!" category, the UX community is going to experience an explosion of vibrancy thanks to blogs and wonderful article-based sites like Boxes & Arrows, A List Apart, UXmatters, and others. I think there's plenty of room for growth in this area.
Because of the previous bullet, the importance of ridiculously expensive professional organizations who publish ridiculously expensive professional journals will decrease... though not fast enough for my taste.

Am I the only one who doesn't love the iPod UI?

2007-06-21T06:37:00.000-04:00

I love my iPod. There's something magical about burning several drawers full of CDs onto a device I can stick in my pocket. I even use iTunes to buy music, though not frequently.

(Side note: Hey, music industry, I have 1000s of songs on my iPod and NOT ONE of them is pirated. But I have two laptops, a desktop, two iPod shuffles, one iPod, one Disney MP3 player, and I'd love to find a car stereo that let's me store my music directly on the stereo instead of trying to remember my iPod whenever I drive somewhere. I have reason to copy my music between all these places. Stop making my life difficult. )

(Side note: Hey, Apple, that 99 cents-a-song thing was a great gimmick when you launched iTunes. But that what is was... a gimmick. It's over, man. First of all, 99 cents per song isn't cheap. Second of all, there's no real reason why all music should cost the same amount. Here's the deal - there's a whole bunch of music on iTunes that I'd pay a quarter to buy, but I won't pay a buck to buy. For a quarter, I'll try new things. I'll experiment. I'll get some older nostalgic songs from my misspent youth. For a buck, I'll get stuff I know I'll really like, and I'll be careful. If you took your music catalog and made half of it 25 cents a pop, you'd make more money.)

Anyway, back to the iPod and its UI. I had heard all about how "simple" the UI was. I expected to love it. Instead, I'm a bit shocked by some of the fundamental flaws in the UI that irritate me on a regular basis. Here's my top 3:

Multi-modal inputs stink. It annoys me that I need to press-and-hold the Play button to turn the thing off. And it turns on when you touch it. And the screen goes dark to save energy while it's playing. So how do I know that the thing is really off? I don't. And I've repeatedly experienced times when I have shut the thing down and then stuck it in my pocket or my backpack only to discover hours or days later that it must've turned on by mistake and the battery ran down to nothing. Hey, I have an idea! How about a fricking ON/OFF switch?
I have a ton of "specialty" playlists that I listen to on very rare occasions. In practice, I only have 3 playlists that I listen to on a regular basis (1. "3 or more stars" which translates to "every song that I like." 2. "Relax" which translates to "mellow songs that I listen to when I'm falling asleep." 3. "Wake Up" which translates to "rocking songs that I listen to when I need an adrenaline boost.") Why can't a bookmark those 3 playlists at the top of the iPod hierarchy so I can quickly get to each of them? I configured it so that I have "Playlists" at the top of my hierarchy, but considering that I have about 50 playlists, it's still not that easy to get to the exact playlist I want using the stupid spinwheel.
And the biggie. There are two ways I listen to music. I either listen to a playlist or a listen to an album. When I listen to a playlist, I want it to be in random order. When I listen to an album, I want it to be in track order. Who wants to listen to "American Idiot" in random order? But changing from random to ordered is a pain on the iPod. I can understand, perhaps, why they don't want another physical control on the iPod (though it works fine on the iPod Shuffle, which has a lot less room to work with), but at least make it a toggle button at the top of the software hierarchy. It's not a "preference". It's a frequently changed setting. Don't make me dig around for it. And hey, as long as we're talking, how about having a separate setting for albums, where you default to "track order" when listening to an album? I'm sure I'm not the only person who treats an album differently than a playlist.

Who cares about finding new usability problems?

2007-06-20T11:27:00.000-04:00

I interact with a lot of UXers in my company and elsewhere. Based on those interactions I have to ask, "Why do we spend so much time talking about the best way to evaluate usability or find usability problems?" It's clear that the biggest obstacles to overcome in order to deliver a usable product have very little to do with knowing what the usability problems are, and everything to do with figuring out a way to fix the usability problems you already know about.

I'm not saying that running usability tests is a worthless activity. I'm not saying we shouldn't think about running tests in new ways (particularly more efficient ways). But I think most products very quickly reach the point where they know about more usability problems than they have resources to fix. At this point the return on investment for discovering new problems is very low.

Obviously, most usability testing is done on NEW design going into a product (or website or whatever), so one might argue that in this case usability testing is still obviously needed. But again, in my experience this isn't true -- by the time the usability test is run, so many compromises have been made to meet schedules that the usability tester already knows what the user is going to complain about. It's just busywork at that point.

In my career, I've run precious few usability tests where I honestly did not know going in what the best design was, and the usability testing provided exactly the right insight that I needed to make the right design decision. I love those moments. But in my opinion they are the exception to the rule.

(Note: This opinion does not apply to user research, which I find is almost always valuable and worthwhile)

Buyer's remorse and the Sony PS3

2007-06-18T09:07:00.000-04:00

I'm a video game junkie. For the most part, I think video game systems are really good investments. Because my favorite genre is RPGs, and good RPGs are notoriously long, all I need is one or two great games to essentially justify the purchase of the system. For me, the comparison point for entertainment value is pulp fiction. I can go on Amazon and buy a paperback pulp fiction book for about $10. For example, I'm a big fan of Charlaine Harris, and I can pop over to Amazon and buy "Dead Until Dark" for $7.99 plus shipping. It probably takes me 5 hours to read a typical Harris book, so I'm paying about $2 an hour for the entertainment of book. This is roughly the same price I pay to watch a Netflix movie (Netflix should actually be cheaper, but I can never remember to return the damn movies after I watch them). Without concessions, going to the movies in the theater is a bit more expensive -- more like $4 an hour, but still fairly reasonable.

On the other hand, a video game system seems really expensive - we paid about $400 for our XBox360, and it didn't even include a game (or a second controller... grrr). If you include a game and a controller, the XBox360 was $500. Pricy, right? But let me pick one example from the XBox360 -- Elder Scrolls IV: Oblivion. This is one of my favorite games of all time. I am confident that I have played it for at least 200 hours. That means that if the only game I ever play on the XBox360 is Oblivion, I paid about $2.50 an hour for the entertainment value of the system. And considering that I've played many other games already on the 360 and that Fable 2 is supposed to come out this Christmas (the sequel to my favorite game ever), it's safe to say that eventually the entertainment value of the 360 will be pennies on the dollar.

We bought the Sony PS3 at Christmas for $600 and I have yet to play a game on it. Not one. Admittedly, one of the main reasons we bought it was the Blu-Ray support (high definition DVD), and we use that occasionally, but so far there just aren't any games I'm interested in playing.

And yet I STILL did not have buyer's remorse... until last night. I had a Blu-Ray movie I wanted to watch. I fired up the PS3 and it told me there was a required System Update that I needed to install. It had told me this a couple times and I ignored it, but I decided to bite the bullet last night and just install the thing before watching my movie.

An HOUR AND A HALF later the update was still not installed, there was no progress report (the PS3 would just periodically try to reboot itself to let me know it was still doing something), I was afraid to hard-reboot it (which is not a great idea during system updates) and I gave up and went to bed. This morning I checked on it and it told me... get ready for it... that it was now ready to install the update. That's right. During the hour and a half that it was doing whatever last night, it wasn't actually installing the update... it was just getting ready to install it. And it wasn't downloading it either, because it did that first (with a progress indicator, thank goodness, though it was a fake progress indicator) and we have broadband.

I wanted to throw the thing out the window.

What is Sony thinking?

The user testing rope-a-dope

2007-06-14T08:59:00.000-04:00

It's important to distinguish between situations when a development team is not implementing your design because they don't have the resources to do it and when they are not implementing your design because they disagree with it (or, perhaps, think that design doesn't matter). Obviously the correct response to these situations is different. The trouble is that sometimes it's hard to tell the difference between them, because developers sometimes use resources as an excuse to not do designs that they really don't believe in.

I was talking to a colleague yesterday who was having an issue with her development team. The developers on the project had created a design that (I'm not making this up) utilized multiple levels of tabs, as well as an bizarrely-placed "action button" that served as essentially a menu item. She provided an alternative design that fixed these problems. The response? The developers want her to run a series of usability sessions to verify with users that their original design is actually a problem, because they are short of resource and don't want to fix this if it isn't necessary. I call this the user testing rope-a-dope. Amazingly, this meeting happened after I wrote yesterday's blog entry about most design issues not requiring user input... using tabs-within-tabs as an example! We don't need to talk to users to know this is bad design. Heck, if the users told us they liked the tabs-within-tabs, we'd ignore them as statistical anomalies. The developers are trying to use user testing as a way to delay the decision long enough to make changing the design impossible.

It's amazing to me that a team would request UX support and then not listen to the UXer's guidance on design.

Is there such a thing as too much technical knowledge?

2007-06-13T13:44:00.000-04:00

When I started my career in User Experience, back before it was called User Experience, I proudly avoided becoming too advanced in my technical knowledge of the product I was supporting. There was a perception at the time that if a UXer became a domain expert they'd lose touch with how user's perceive the product (or at least novice users). We even coined a term for when a UXer would get a little too close to the development team -- "going native". If we caught a UXer saying things like, "Well, if users don't understand shell scripts, they shouldn't be using the product", they were quickly admonished for going native.

Obviously every UXer had to have some domain knowledge, but there was a largely unspoken agreement that we should avoid going too far with it. Bear in mind, when it comes to enterprise software, technical domain mastery is very expensive. For example, my first job was working on DB2 on the mainframe... becoming a domain expert could take a decade. But the issue isn't laziness, it was philosophical -- a UXer should be an expert in design and usability methodologies, not in whatever product domain they happen to be supporting. AND not only is domain knowledge not necessary, it could also be dangerous, because it could cause the UXer to not see usability problems that a non-expert would encounter.

I now think I was completely wrong.

Well, not completely wrong. I still believe that many design issues require no domain knowledge to recognize and fix, and most product designs are so bad that a decent UXer can spend many releases just trying to fix standard design problems without ever needing more in-depth knowledge about the product. In other words, I don't need to know anything about a product to point out that the developer's grandiose tabs-within-tabs-within-tabs design might be flawed.

But at some point you start to hit the really tough design decisions. Where the answers are not obvious, and it becomes unreasonable and expensive to always address those questions with "let's run another usability test." This is where the intersection of design abilities and technical domain knowledge becomes truly valuable. The technical architects have the domain knowledge and they care about the users, but they (usually) aren't design experts and unlike the UX professional, they have many competing incentives. The UXer only cares about the user.

I now believe that technical domain knowledge is one of the most important tools in a UXer's toolbox, and should be pursued with vigor.

Book Review: "The Myths of Innovation" by Scott Berkun

2007-06-11T10:14:00.000-04:00

Have you ever been to a party and met someone with a great job and a great sense of humor and ended up spending the entire party drinking beer and swapping interesting stories? That's what Scott Berkun's new book, "The Myths of Innovation", felt like to me. There are lots of books on my shelf that I know I ought to read, and many of them I struggle through and afterwards feel like it was a valuable investment of my time, however painful. This wasn't one of them - this is one of those rare books that feels like reading for pleasure, and yet you learn something along the way.

And I might add that the colophon alone is worth the price of the book (a sentence that perhaps has never been written).

I wonder how much time and research Berkun did on this book before he came up with the idea of orienting the book around myths? Was that the idea all along? Or did it emerge over time? Because it turns out to be a perfect way of presenting the material. First, everyone loves to feel like they know something that other people don't - the truth behind the myths. This "peeking behind the curtain" approach is a great way to keep the material interesting. Second, innovation is such a complex area that it would be very difficult to write a book about what innovation is -- it's a lot easier to talk about what it isn't. But by providing the boundaries via the myths, it inevitably provides great insight into how innovation really happens. And third, myth debunking seems to fit Berkun's auctorial voice. His casual, conversational tone is not only funny and engaging, but it naturally allows the type of speculation and interpretation that is necessary for the topic. In other words, a textbook-style examination of innovation would be a very poor choice.

While I enjoyed the entire book, I particularly enjoyed in the section on the myth of "the best idea wins". In it, Berkun describes the many factors that are involved in whether an innovation succeeds, and how being the "best" is only one of many factors. When it comes to design innovation in established software, the impact of "dominant design" is always a challenge - what is the cost of moving to something better when you have a large customer base who already knows how to use the product? One example in the book is the QWERTY keyboard that we all know and loathe. But to lesser degree this is always the case - I can't convince my wife to move from Paint to Photoshop for editing pictures because she knows how to use Paint. Whenever I try to tell her about how many great features there are in Photoshop, all she hears is "blah... blah... blah... [it will take lots of time to learn]... blah... blah... blah."

I recommend this book highly to anyone who has a job where innovation matters... which is just about everyone.

The Joy of Grids

2007-06-08T08:39:00.000-04:00

Yet another reason why the internet is a wonderful thing. I found this presentation from Khoi Vinh from his Subtraction blog. It's a walkthrough for how to design web pages using grids, and it's a great tutorial for the uninitiated.

What did people do before the internet? Talk to each other? *shudder*

Agile development and user experience

2007-06-07T10:51:00.000-04:00

There's been a couple recent articles on agile development and UX:
Four Factors of Agile UX (on UXMatters)
Lessons from Google Mobile (on Boxes and Arrows)

I think this is an interesting topic. I have a colleague working in an agile development team, and it has definitely been a mixed blessing. On the one hand, the frequent iterations allows frequent opportunities to fix problems. On the other hand, the frequent iterations makes it difficult to fix BIG problems, particularly if the big problems require significant user testing to find the solution.

Here's what I think are some basic guidelines for how to do UX well in an agile environment:
1. Make sure the frequent iterations are available to users as beta code - this will likely be the best opportunity to get user feedback, even if it is informal.
2. Focus more on the "professional designer" role rather than "usability tester" role - most design problems do not need user feedback, they just need a smart designer.
3. Embrace the positives, accept the negatives - if the process does not allow big problems to be fixed, then focus on fixing the little things rather than tilting at windmills.
4. Set a user experience vision - it's easy to miss the forest for the trees in agile teams, so make sure that you're constantly evolving towards a well-understood goal, rather than constantly playing whack-a-mole with whatever the design defect du jour is.

SaaS as a user experience tool

2007-06-01T11:40:00.000-04:00

Software as a Service (Saas) is an intriguing way to solve the problem I describe below. First, of of the reasons enterprise users want to avoid change is because of the cost of deploying the changes. SaaS allows a product to make changes without any deployment cost. Next, it allows incremental improvements to be made to the software. One of the great things about websites is the ability to make small, frequent changes. These small changes are not disruptive to regular users yet over time it allows substantial improvements to be made. Application middleware that requires user installation and maintenance don't inherit this benefit. But SaaS can solve this problem - buying the middleware doesn't mean you have to take it and install it and host it and maintain it... it just means you have access to it.

There are problems with this approach, of course. The biggest of which, to me, is the ability to extend a product with third-party software, which is critical in building a viable ecosystem for middleware. How do you extend something that you don't host yourself? This is tricky, but it's solvable.

Although SaaS is a new buzzword, it's not a new concept. But given the amount of time and expense that customers spend on installing and maintaining middleware, not to mention the user experience benefits, it might be useful to push the boundaries of SaaS to include traditional middleware offerings.

On release cycles, change, and stability

2007-06-01T10:01:00.000-04:00

Users hate change. Once they invest in learning a product, they don't want it to change, even if the changes are theoretically for the better. In enterprise software, they are particularly interested in the stability of the code base AND the stability of training. If they have a large organization trained on one version of an product and we tell them, "We've changed everything in the new version! It's way better!!", they do not get excited. They get nervous and start calculating migration costs. Users want to settle on a stable release of the product and stay there until something happens that forces them to move (like the product going End of Service). Users tell us to stop putting out new releases... slow down... extend the release cycles. Users hate change.

Users want their new features added to the product, and they want them added NOW. Sure, the product is pretty good, but without features X, Y, and Z, it simply isn't good enough. And with enterprise software, when a customer tells us they want X, Y, and Z, chances are they are paying a LOT of money for the software, so we damn well better listen. Of course, each customer has a different list of what X, Y, and Z are, they don't care about the other customers' requirements, and they hate unnecessary change. "Unnecessary change" means "changes that my company doesn't need." Users do not want to wait for their favorite features to be added.

This dilemma is particularly difficult for user experience practitioners. Customers don't want to retrain, yet we're only got, perhaps, one opportunity every two years (depending on the length of the release cycle) to make improvements in the product. By essentially saving up all the improvements for two years we inevitably introduce fairly major changes with each major release - which is bigger change than customers want AND slower change than customers want.

What's the solution? It's possible that the answer is "there isn't one", but I'm wondering whether Software as a Service isn't a pretty good way of getting around the problem. More on that in my next post.

Breadcrumbs: where you are or where you've been?

2007-05-31T20:06:00.000-04:00

I had an interesting discussion with a colleague about breadcrumbs recently. He was doing some work on design patterns and the issue of breadcrumbs came up. The initial pattern proposal basically mirrored Jakob Nielson's recent article on breadcrumbs. In other words, breadcrumbs should show where a user is in the navigation rather than showing them where they've been. As Nielson puts it, "Breadcrumbs should show the site hierarchy, not the user's history."

Of course, the obvious problem with this is that many sites are not hierarchical. So Nielson immediately follows up the statement above by saying, "For non-hierarchical sites, breadcrumbs are useful only if you can find a way to show the current page's relation to more abstract or general concepts." Further proof that confidence is often more persuasive than knowledge, I suppose.

The interesting question from my point of view was whether Nielson's pithy, unambiguous guidance applied to web applications. In most web applications, users don't navigate directly to sub-pages in the application (one of the primary benefits to hierarchical breadcrumbs, according to Nielson) , applications are often not hierarchical (for example, they include tasks), they discourage the use of the browser Back button (which Nielson think removes the need for history), and there are often omnipresent navigation panes that assist users in understanding where there are in the object hierarchy.

For example, let's say I'm in the process of performing a multi-step process like checking out of an online store. As part of this process, the application provides the option to leave the main task path to perform other actions (like creating a profile). How would a hierarchical breadcrumb trail work in this case? Not at all, as far as I can tell. If the user chooses to leave the profile creation task and return to the checkout process, should they use the Back button? Perhaps, but provided a breadcrumb trail that allows the application to handle the move has obvious benefits.

Perhaps breadcrumb patterns are more complicated than they first appear.

Blaming developers for usability problems

2007-05-29T11:33:00.000-04:00

I'm sure there are plenty of situations where a developer makes a design decision without the proper skill/knowledge/thought/information and the decision worsens the usability of the product. It probably happens all the time. But to be honest, I think way too much attention is focused on solving this problem. In books and articles I read, there is often a sometimes unstated assumption that if we could just get developers to understand the fundamentals of design a bit better, they could make better decisions and usability would dramatically improve. I don't buy it.

The developers I work with are smart, conscientious people with a decent working knowledge of design... at least good enough to recognize design problems, but perhaps not solve them. They want to do the right thing. They appreciate that usability is important. And they take pride in the quality of their work. The problem is that good design is often harder to contain than bad design. Not always, but often. And developers have VERY strong incentives in place to make their code deadlines. So they are put into a position where they can either miss their deadline to do the better design or they can make their deadline to do the worse design... and all the external incentives say to choose the latter.

And this isn't always the wrong choice. Features DO matter, and spending extra time on design lessens the number of features you can do. Clearly, there's a balance.

But I tire of this assumption that bad design happens out of ignorance, especially the ignorance of developers. I think that's the exception to the rule.

Book review:"designing the obvious" by Robert Hoekman, Jr.

2007-05-24T07:19:00.000-04:00

I recently finished Robert Hoekman's new book, "designing the obvious: a common sense approach to web application design". I enjoyed the book and thought that Hoekman had some good insights into what it means to produce quality design, though I also had some disagreements and found some of his advice to be of limited value in the domain of enterprise software.

One of the things that liked best was the section on "understanding users". This has long been a pet peeve of mine -- while obviously good designers needs to understand their users, I've often felt that running usability tests on design were of limited value. And I think the issue is that we often ask the wrong questions. Hoekman has a great summary of this problem:

For example, if I were designing and building an application used to track sales trends for the Sales department in my own company, my first instinct... would be to hunt down Molly from Sales and ask her what she would like the application to do. Tell me, Molly, how should the Sales Trends Odometer display the data you need?

I would never ask my father the same type of question. My father knows next to nothing about how Web sites are built, what complicated technologies lie lurking beneath the pretty graphics, or the finer points of information architecture. He wouldn't even be able to pick a web application out of a lineup, because he doesn't understand what I mean by the word application...

What my father does know is that the model rockets he builds for fun on weekends require parts that he has to hunt down on a regular basis... If I told my dad he could buy these parts online, he'd be interested. If I asked him how the application should filter the online catalog and allow him to make purchases, he'd look at me like I was nuts.

Molly from Sales would likely do the same thing.

Molly has no idea what your software might be able to do, and she almost certainly doesn't have the technical chops to explain it.

I think this is a great point. We need to understand our users and we need to understand how they use the product (or use our proposed new designs), but we should not be asking them to design our product. We're the professional software designers - we shouldn't abdicate our responsibilities onto the user. It's nice to see Hoekman saying that in print.

I also liked what Hoekman had to say about turning beginners into intermediates. Basically, the biggest proportion of most products' user base is the "perpetual intermediate". Someone who has learned just enough to get by, and has no plans to ever learn more. One of our goals is to help beginners reach this stage. WAS does quite a bit in this space, perhaps most notably in our "Command Assist" functionality in the console, which allows people to transition easily from using the console to using scripting.

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). The simple fact is that there is a cost associated with improving the design of a feature or a product. Designing things well takes more time and people. It usually means that the system is taking on more of the complexity from the user, which requires more coding and testing. Everyone wants good design, but when push comes to shove, I think many of our customers would admit that if better design means fewer features and longer time to market... well, it's not a no-brainer that better design should win the day. It's a balance. Sometimes better design is the right answer, and sometimes time-to-market pressures are too important to lengthen the release cycle to include an expensive, iterative design phase. Being able to tell the difference between those cases is the trick, and not an easy one. But the point is that the "obvious" design techniques that Hoekman discusses are already common design techniques in most shops... when there's time to do them.

But overall I thought it was an excellent book, especially for people who are trying to go from beginner to intermediate in their design skills. It's well-written and engaging, and that counts for a lot.

Is simplicity a valid goal?

2007-05-23T22:14:00.000-04:00

There's been an interesting discussion happening within the online user experience community recently on the virtues of simplicity (or lack thereof). Legendary Don Norman kicked off the debate in an essay titled "Simplicity Is Highly Overrated". Excerpt:

Why is this? Why do we deliberately build things that confuse the people who use them?

Answer: Because the people want the features. Because simplicity is a myth whose time has past, if it ever existed.

Make it simple and people won’t buy. Given a choice, they will take the item that does more. Features win over simplicity, even when people realize that it is accompanied by more complexity. You do it too, I bet. Haven’t you ever compared two products side by side, comparing the features of each, preferring the one that did more? Why shame on you, you are behaving, well, behaving like a normal person.

Basically, Norman's argument is that people say they want simplicity, but when it comes time to make a purchase decision, they go for features.

Joel Spolsky followed up on Norman's essay with some thoughts on his own experiences, specifically that people often confuse simplicity with aesthetics. Excerpt:

Devotees of simplicity will bring up 37signals and the Apple iPod as anecdotal proof that Simple Sells. I would argue that in both these cases, success is a result of a combination of things: building an audience, evangelism, clean and spare design, emotional appeal, aesthetics, fast response time, direct and instant user feedback, program models which correspond to the user model resulting in high usability, and putting the user in control, all of which are features of one sort, in the sense that they are benefits that customers like and pay for, but none of which can really be described as “simplicity.” For example, the iPod has the feature of being beautiful, which the Creative Zen Ultra Nomad Jukebox doesn't have, so I'll take an iPod, please. In the case of the iPod, the way beauty is provided happens to be through a clean and simple design, but it doesn't have to be. The Hummer is aesthetically appealing precisely because it's ugly and complicated.

Not surprisingly, not everyone thinks simplicity is overrated. On Scott Berkun's blog, he provides a defense of simplicity. Excerpt:

It’s easy to confuse success with quality, and both articles discount our secret inability to make satisfying choices. We are attracted to things with more features, that cost less, or come in larger quantities, despite our inner suspicions that we’re likely to complain about those purchases soon after. We date people, eat food, take jobs and buy products for superficial, misguided reasons all the time. We’re easily seduced, and every marketer knows we always have been and always will be.

But we shouldn’t confuse the success of feature-laden crap as a signal for the irrelevance of simplicity any more than the success of Rocky IV and Burger King signaled the irrelevance of good film-making or fine dining. It just means there are gaps between what we need, what we want, and why we buy, and that the masses are by definition less discriminating than the niches of people with refined tastes for a particular thing.

Berkun is basically arguing that there is still a place for simplicity, even if most folks don't give enough thought into their purchases to look for it. He also concludes by saying, "Simple design doesn’t mean brain death: it means being being as simple as necessary to achieve a great experience for a group of people, but no simpler."

When it comes to enterprise software, I think this discussion is even more relevant. Those of us in user experience often here the calls to deliver "simplicity", whether we're working on a small troubleshooting utility or highly available, performance-tuned, enterprise-capable application serving capability. "Make it simple!" we're told. This has long been one of my pet peeves, and the articles above touch on my beliefs, but don't quite capture them. Ironically, in his defense of simplicity, Berkun comes closest to capturing why I think "Make it simple!" is a mistaken goal. I think that saying "...as simple as necessary... but no simpler," is another way of saying "simplicity is NOT the goal."

Let me use an extreme example to make my point. Let's say we could create an application server product tomorrow that is so simple that all it requires is an on/off switch (I believe this can be done through the use of pixie dust). We release it and everyone raves about how simple it is. Until someone tries to use it and asks, "Uh, it was really easy to turn on, but I need a way to actually deploy my application." Well, okay, so we add a button for installing an application. That's not too bad, just one more little button. Still simple... and then someone says, "Great, I have my application running. Now I have an update to the application. What do I do?" Well, we could add another button for updating an existing application, but why bother? The product would be much simpler if we just have the user create a new server and install the new version of their application on it -- then we don't need to add another button!

Obviously, that would be a terrible decision. Why? Because creating a simple product is not the goal. The goal is to create a product that allows users to achieve their goals... and sometimes those goals are complex. Especially when it comes to enterprise software. If a customer has a goal of trying to maintain the value of their legacy systems by creating external services on top of the old systems that can communicate with newer systems, an on/off switch is not what they are looking for.

Obviously, unnecessary complexity is a problem, and IBM needs to do a better job of eliminating unnecessary complexity. But not because simple = good and complex = bad. We need to reduce unnecessary complexity because it interferes with a user's ability to achieve their goals. Simplicity, in and of itself, is not particularly relevant.

Side note: Of course, the challenge for the user experience engineer is that a feature that adds unnecessary complexity for one user is absolutely critical for another, so providing the features necessary to allow users to achieve their goals while also eliminating unnecessary complexity sometimes makes me feel like a circus contortionist. But that's a topic for another day.

Tech Talk with Mom: Explaining what I do

2007-05-23T21:52:00.000-04:00

Me: ...as I've explained before, I'm the Lead Architect for User Experience for the WebSphere Foundation.

Mom: That's nice, dear.

Me: Uh, thanks. Basically, I try to improve the usability of software products. Usability and user experience or pretty much the same thing. It's also known as human factors, user-centered design, outside-in design, human-computer interaction, consumability, interaction design, user engineering...

Mom: You engineer users?

Me: Well, no... okay, so that might not be the best term.

Mom: So your job is to make things simple?

Me: Exactly!

Mom: If making things simple is your goal, why do you have twenty different names for what you do?

Me: Have you ever played Whack-a-Mole? It's the same basic idea.

Mom: Uh huh.

Me: Anyway... we have a team of usability professionals who work on IBM WebSphere products to help simplify the design. We have teams of developers who write the code, and we work with them on new features that are going into the product.

Mom: Why can't the developers do their own design?

Me: Well, they can. They do. There are different types of design. First there's the design of the code itself. Developing code is difficult work, they need to figure out the best way to design their code to anticipate future enhancements and extensions, they need the code to perform well, they need their code to work with the other hundred developers in their organization, and so on. On top of this, developers are constantly being asked to pick up new programming models and languages. It's a tough job.

Mom: If you aren't a developer, how do you know how tough it is?

Me: I hang out with developers, and they love to talk about this stuff when they've been drinking. They think it attracts the ladies.

Mom: Does it?

Me: Not so much. Though I've seen the "polymorphism" line work a few times. The point is that developers design the code, but our team focuses on the user interfaces. Developers often are asked to design user interfaces as well, but it's tough for them to do.

Mom: Why?

Me: The biggest problem is probably a conflict of interest. Developers everywhere are under intense pressure to get their code done as fast as possible.

Mom: That's dumb.

Me: Well, not completely. Remember, we're talking about developers here, not normal people. They actually like to write code. They're like kids drawing pictures in kindergarten -- you need to know when to take away their crayons. But more importantly, by definition the developers are intimately knowledgeable about the inner workings of the program, which makes it very difficult for them to put themselves into the head of a user who is just getting started. It's very difficult for people to remember what it's like to not know something.

Mom: So you're saying that your ignorance is actually a job skill?

Me: Exactly!

Mom: Your father will be so proud.

Me: So even though it might seem like a strange system, it's actually setup so that different people have different focuses... the developer wants to get the code done on schedule, the usability person wants the design to be simple, the tester wants the code to function reliably, the guy in marketing wants every new requirement in the product by next Tuesday... and then by all of us working together, we try to achieve the right balance between all the competing interests.

Mom: You're not going to start singing Kumbayah again, are you?

Me: Dad says I have a nice singing voice.

Mom: He also thinks Gilligan's Island is the funniest show on TV.

Me: Good point. So... it's tough for developers to focus their attention on creating usable user interfaces while juggling all their other responsibilities as well. But there's another piece to what we do - we test our designs with users before the product ships so we can know that we've done a good job. That way we're able to catch a lot of problems that otherwise wouldn't be noticed until after the product ships. So basically we work as customer advocates, sometimes based on actual customer feedback, sometimes via general customer knowledge, and sometimes by just making sure that the customer needs aren't forgotten in the push to get the products out the door.

Mom: So you're ignorant about the code, and when you don't know how to design something, you just go talk to customers?

Me: Pretty much.

Mom: And they pay you for this?

Me: It's a great job, yeah. But it's not really as easy as it sounds. Even though we're not developers, we need to develop a good technical knowledge about our area if we really want to contribute decent design. Plus there's different design guidelines depending on whether you're designing for a web application, a website, an installed program, an installation process, a command line interface, a scripting interface... and so on. It takes experience to tell the difference between a minor design issue that will be mildly confusing for users and a major design problem that will cause hundreds of support calls. Designing usability sessions so that you get actionable results is a unique skill. And understanding the right balance between customer requirements, usability concerns, marketing needs, schedule pressures... these are things that never get easy. And that's not to mention trying to understand the impact that things like SOA or open-source software or new programming languages will have on the product's usability priorities in the future. See? So that's what I do.

Mom: That's nice, dear.