Thursday, December 4, 2008
Saturday, November 22, 2008
Faux simplicity
It's finally gotten cold enough here in North Carolina (it's 24 degrees outside right now) that I climbed up in the attic and got out our space heater for the kids' playroom. In doing so, it reminded me of one of my least favorite design techniques - what I call "faux simplicity". Take a look at the control panel for the heater:
Wow... it's soooooo simple that it only has ONE button! They even advertise the "1 Touch" interface below the panel. What could be simpler than one button?
How do you turn it on? You click the button.
How do you turn it up to the next degree setting? You click the button and the temperature goes up one setting.
How do you switch it from high to low? You keep clicking the button as it toggles through the high and low temperature settings.
How do you set it be always-on? You click the button until none of the temperatures are lit up.
How do you turn it off? You click the button and hold it down until it powers off.
SIMPLE! One button!
As a real life example, I usually have it set to Hi and 75 degrees. My kids wake up and they're cold so they click it twice (once to Hi/80 then to Hi/Always-on). Then I walk in, irritated, and tell them that the heater doesn't get any hotter just because it's set to always on (they think 75 degree is the temperature that the heater is running at, not the temperature that it shuts down automatically). So I want to switch it back to Hi/75. By clicking the button TEN TIMES.
1. Lo/60
2. Lo/65
3. Lo/70
4. Lo/75
5. Lo/80
6. Lo/Always-on
7. Hi/60
8. Hi/65
9. Hi/70
10. Hi/75
Woops... I clicked too fast and ended up on Hi/80. Now I need to click 11 more times to move it down one degree setting.
By having a single button, they didn't make it simpler, they made it more complex. They didn't simplify the feature set, only the interface, by overloading their single button with a bunch of different capabilities. The interface would be much simpler with an on/off button, "temp up" and "temp down" buttons, and an "always on/temp control" toggle. In this case, 4 buttons is simpler than 1.
The iPod has a similar example of this - the fact that you need to turn the iPod off by clicking and holding down the Pause button. This annoys me everytime. Please, people, On/Off buttons do not add unnecessary complexity in items that are turned on and off repeatedly!
We experienced this in one of our products a few years ago. Customers were complaining that our install was too difficult. At the time, our install process accomplished two things: it asked the few standard, necessary questions so we could put the product onto the machine (install directory, etc.), and a few questions that were required as "pre-configuration" so that the product would work the first time you used it (to our credit, we had reduced this set down to a bare minimum). So what was the proposal to simplify install? Simple! We'll separate the install into two parts! One part is the normal install that you see for every product and the second is a post-installation configuration wizard. By pulling the configuration out of the install, we'll make install way simpler!!
Of course, that's not simpler at all. From the customer's point of view, "install" translates to "all the crap I need to do before I can get the product running", including the post-installation/pre-configuration stuff.
We began referring to this as "small i" install and "big I" Install. Small i install is the "putting the bits on the box" process, and big I Install is the whole enchilada for completing and managing the installation. And we were able to successfully make the point that shifted some complexity from one place to another within the Big I Install is not simplifying anything for the customer, it's just changing where they encounter the complexity.
As discussed previously, "simplicity" is not a valid goal... it's a distraction.
Posted by Terry Bleizeffer at Saturday, November 22, 2008 3 comments
Tags: design gaffes, simplicity
Thursday, November 20, 2008
Multiple instances of one persona?
A colleague has run into an interesting problem during the development of some personas... er, personae. They have a situation where there are common scenarios that require collaboration between different people that all have the same job description/role/tasks/responsibilities. In other words, normally it would be a no-brainer that these different people could be represented easily with a single persona because there aren't any significant differences between them that would merit creating an entirely new persona.
But they work together. If you create a single persona (say, "Elvis"), how do you write the scenario to describe the collaboration ("Elvis sends an instant message to Elvis to check on progress...")?
But if we create 2 personas that are basically identical except for the name, then it doubles the amount of reading that someone would need to do to understand the personas. And there will inevitably be confusion on the part of the consumers ("Hey, Elvis and Jerry Lee look almost the same... why did I have to read both of these damn things?").
Oddly, I don't recall seeing any best practices on how to handle this situation, even though I suspect it's a common one. If anyone has any pointers or advice, I'd appreciate it.
Posted by Terry Bleizeffer at Thursday, November 20, 2008 3 comments
Tags: personas
Wednesday, November 19, 2008
Null sets in girl's bikes
It's Christmas time and I'm thinking about buying my 8 year old daughter a new bike. I'm trying to find a bike with 20" tires that also has multiple speeds (she has a single speed bike now and is getting frustrated that she can't shift gears on our bike rides). So I was looking at some bikes on 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?
Posted by Terry Bleizeffer at Wednesday, November 19, 2008 0 comments
Tags: design gaffes
Tuesday, November 18, 2008
UPS: Worst customer experience of my life
I was in Barcelona last week for a customer conference. Yes, envy is a natural reaction to that statement. I was running a series of customer feedback sessions throughout the conference, and as preparation for these sessions, I shipped a box of materials to Barcelona via UPS. This turned out to be a mistake of colossal proportions.
To understand just how ridiculously bad UPS handled this shipment, I need to go into boring, gory detail and describe step-by-step the series of events that took place. For those who understandably don't want to read the full narrative I will summarize it in one sentence: The box arrived in Barcelona on Tuesday the week before the conference but never made it to the conference center... I finally gave up on it nine days later.
Here's the full story:
I received shipping instructions from the conference coordinators, and they requested that boxes should arrive on Wednesday, Thursday, or Friday the week before the conference. The conference began on Monday, with some early registration on Sunday night. One of the things in my box was 800 flyers to be inserted into everyone's conference messenger bag that they receive when they register, so it was important that the box be waiting for me when I arrived on Saturday so I could do all the inserts. To make sure this happened, I sent the box out the Friday before it needed to be there and specified a Wednesday delivery.
On Tuesday afternoon, I got a call from UPS. They said they tried to deliver the package, but they weren't able to do it because the recipient wasn't there. I told them to re-deliver it the next day (as originally scheduled), and I was encouraged because I knew the package had made it to Barcelona... early! Great, no problems.
I arrived on Saturday and the box wasn't there. And UPS was closed on Saturday and Sunday. No useful information in the tracking information online. We called UPS in America and tried to get a number for someone in UPS Spain - no can do. We said, "Listen. You work for a multinational corporation. I work for a multinational corporation. I guarantee that if I had to get someone from IBM Spain on the phone on a Sunday, I could do it." The UPS person said, "I can't even make international calls."
So on Monday morning we called UPS -- they opened at 9:00 AM. They said the problem is that they can't deliver the package because it's stuck in customs and they need someone to fax over a passport. Of course, they'd previously said they tried to deliver it on Tuesday, but the person had no record of that happening. We asked why they hadn't called to let anyone know about the problem... they said they weren't sure. So we asked how long it would take to get through customs, and they said, "A few days." We asked them to expedite it and they said they'd try and to call back that afternoon for more information.
We called back Monday afternoon and they said it hadn't cleared customs yet. They told us to call back in the morning.
We called back on Tuesday morning and they said it hadn't cleared customs yet but they expected it to clear that day, so we could call back in the afternoon and either pick it up ourselves or arrange deliver the next day.
We called back on Tuesday afternoon and it had cleared customs! Yes! We said, "Great, we'll come to pick it up right now." And they said, pick it up? No, you can't pick it up. We have to deliver it. Tomorrow. Okay, fine. We asked them to mark it urgent so it would be delivered in the morning. They said, "It wasn't marked urgent when it was shipped." We explained that things had changed since it arrived in Barcelona a week ago. They said, "No, we can't change something from not urgent to urgent. It will be delivered sometime on Wednesday, but we can't give you any 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.
Posted by Terry Bleizeffer at Tuesday, November 18, 2008 3 comments
Tags: customer service, ups
Hmmm... that's a good question
Posted by Terry Bleizeffer at Tuesday, November 18, 2008 1 comments
Tags: design gaffes, time-warner
Thursday, August 7, 2008
Helpless Desks
My old basic G router was starting to have some issues, so I decided to upgrade to a new Wireless N router. I installed it last Sunday night to be sure everything was working for Monday morning. I work at home full-time, so I didn't want to spend time doing router configuration during work hours. Fortunately, the configuration was fairly painless (even though I had to configure 3 laptops, 1 desktop, an XBox 360, and a PS3 to communicate with the new router). Security was turned on, of course, and I tested the internet connections on all the machines and everything worked fine... and I went to bed content.
When I got up the next morning the first thing I did was fire up my program to tunnel into my corporate intranet (which I run non-stop throughout the work day). And it didn't work. My internet connection was working fine. The tunneler was successfully communicating with something. But no access to the intranet. Dang. So I troubleshooted for awhile and got nowhere.
Finally I called the Help Desk for my company's intranet. The first thing they asked me to do was bypass the router and connect directly to the cable modem. The tunneler worked fine, which meant that it was definitely an issue with the router. But they don't provide support for routers, and as far as they were concerned the tunneler was working fine, so they closed the ticket and hung up, telling me to call the router Help Desk.
So I called the Router help desk. The first thing they asked me was whether my internet connection was working. I said it was, which meant it was a problem with the tunneler. They don't provide support for the tunneler, and as far as they were concerned the router was working fine, so they closed the ticker and hung up, telling me to call the tunneler Help Desk.
I'm not making this up.
2 hours later I fixed the problem on my own. Apparently the new router (unlike the previous router from the same manufacturer) didn't support IPSec, which was what I was using in my tunneler (by default, not via a configuration choice I had made), so I switched my tunneler config to use SSL and that worked.
So was it a tunneler problem or a router problem? Well, clearly it was both. The problem was that I needed to have the configurations in the two programs working correctly together. This is not an unusual situation. It's bizarre to me that in this day and age Help Desks still seem more interested in closing tickets than providing actual help.
Posted by Terry Bleizeffer at Thursday, August 07, 2008 0 comments
Tags: help desks
Wednesday, July 2, 2008
Verifying 911 service in VOIP
I work from home full-time and I recently decided to switch my second phone line (my business line) to VOIP to save the company some money. I'd been avoiding it because I'd heard negative comments from co-workers about the quality, but the money I was being charged for my nearly constant teleconferences finally made my decision.
And I'm delighted with the change. I haven't had ANY connection quality issues, even when I'm screen sharing at the same time. It's been crystal clear and reliable. And everytime I make an hour-long long distance call and remember that it is costing me nothing, I smile a little. It's wonderful.
Except for one thing. Every couple of days I'll make a call and a voice will tell me that before they can connect me I have to verify my 911 service is still the same number that they have on file. First, I have no idea why they need to keep asking me this. But even worse is that it won't register my keypress until it has spoken the entire message AND all the options. I've heard this message so often I've started hearing it in my sleep... and yet I have to wait to listen to the whole thing, everytime, before it will let me press "1".
I still love VOIP, but somebody needs to fix this.
Posted by Terry Bleizeffer at Wednesday, July 02, 2008 2 comments
Tags: VOIP
Thursday, June 26, 2008
Proof of the difference between survey results and truth
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.
Posted by Terry Bleizeffer at Thursday, June 26, 2008 3 comments
Tags: surveys
Friday, May 30, 2008
Explaining UX to 3rd graders
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.
Posted by Terry Bleizeffer at Friday, May 30, 2008 7 comments
Tags: education, user experience
Tuesday, May 6, 2008
Abject terror!
I'm still not sure how it happened, but somehow I found myself volunteering to go and tell my son's 3rd grade class about what I do for a living. Why did I inflict this on myself? How do you explain user experience to a bunch of 8 and 9 year olds? I can't explain it to adults. My mother still doesn't know what I do for a living. Heck, at this point in my career I'm not sure that "user experience" is a big part of what I do... I'm more of an "Opportunistic Firefighter". There's a bunch of fires raging all over the place... far more than once person can tackle... so I look for ones where we have the best chance to put the fire out, then I wade in with my firehouse and see what we can do. Yes, I concentrate on "user experience" related fires, but as I've mentioned before, if you squint enough, everything is user experience-related.
But I don't think I'm going to explain to them what I really do for a living... that would be far too boring and I wouldn't want to embarrass my son that badly. Instead I think I'll explain something about what a software designer does. These kids are computer savvy, so I think they'll understand the concept that a human being somewhere has to create the websites they visit and games they play. And I think they'll like the part about talking to the human beings that will use the software before it's actually done - game testing is something they "get".
But it's going to be a real challenge to keep the conversation at the right level while still doing a reasonably good job of explaining what design is all about. I think I need some good analogies (like building a house). And I need to avoid completely geeking out (which is an obvious challenge for me) and using professional jargon that they won't understand. It's easy to forget how useful jargon is... but try living without it for an hour.
If I come up with a presentation that isn't awful, maybe I'll post it here via Slideshare so people can make fun of it.
Posted by Terry Bleizeffer at Tuesday, May 06, 2008 3 comments
Tags: usability, user experience
Friday, May 2, 2008
Minimal personas
I wonder if there is some minimum set of information needed before you can really call something a "persona".
Do you need a "person name"? Do you need a photo? Do you need any non-domain personal information?
Obviously one of the challenges with personas is that they can be rejected by uber-geek developers on the grounds that they are egregiously cheesy. One way to avoid that is to remove the cheese. Replace the person name with a job title. Don't mention anything about how many cats they have. Include personal information that is directly related to the design of the product, like, "So-and-so clocks out at 5:00 sharp and whatever he's working on gets forwarded to the next shift," because obviously that might impact how easy it is to forward work.
But one of the goals of personas is to ease communication and make them more memorable by talking about a "real" person. Without the cheese, can this be done? Is it still a persona?
Posted by Terry Bleizeffer at Friday, May 02, 2008 0 comments
Tags: personas
Wednesday, January 30, 2008
Is "consumability" another useless buzzword?
"Consumability" is a term that appears to have been coined within IBM. I'm not sure who coined it or when it first appeared, but I started hearing it thrown around about 5 years ago. At first I groaned and thought, "Oh, great, that all we need... yet another term for user experience." Whoever coined it must have been an executive because it didn't die (grin) and I started hearing it more and more within IBM.
I've since come around and started to really appreciate the utility of talking about "consumability". But what is it? Is it different than user experience?
Carl Kessler, an IBMer who writes the outside-in-thinking blog and wrote Outside-In Software Development (which I reviewed here), has the best definition of consumability that I've seen:
"Your stakeholders primarily want to perform the tasks with your software that directly relate to their business goals. But when they use your software, they'll have to also address some additional tasks that aren't in their direct path toward accomplishing those business goals... We call these meta-tasks... We refer to this impact of meta-tasks as consumability; the more the meta-tasks distract from your product's business value, the less consumable it is."
In other words, consumability is the measure of all the crap you have to go through outside of using the product to directly accomplish your goals.
Is user experience a subset of consumability or is consumability a subset of user experience? Well, the problem I've always had with "user experience" is that it's so ridiculously broad that anything could be claimed to fall under the user experience umbrella. In practice, I think there's a lot of overlap between the two, with a few things that are only in one space and not the other. For example, lowering the price of your product will increase its consumability, but doesn't have an impact on user experience (other than 7th order effects). Likewise, improving the usability of your core business value doesn't increase consumability, because consumability is what you do before you get to the business value.
But there are two reasons I like the consumability term. First, consumability has a very different impact on your product depending on your industry/context/market. For example, consumability is not a big deal anymore for MP3 players. When they first went on the market, consumability mattered more because consumers weren't sure how to get music onto them - or even get music on their computer. Nowadays consumability for MP3 players is little more than identifying the "on" button (which in some cases, like the iPod, is harder than you'd think). On the other hand, in the area of enterprise middleware (my area), consumability is enormously important. Enterprise customers are trying to manage installation and fix levels across huge numbers of servers and development machines. When things get out of synch, bad stuff happens. But they don't buy middleware products because they want to manage installations - that's just something they have to do to reach the business value. As hardware costs shrink and people costs rise, consumability is more often becoming a critical business driver.
The other reason its a useful term is that there's a natural, understandable tendency for teams to want to focus on adding direct business value to their products. During release planning, a common and obvious question is "What's the business value for this feature?" Well, what if your goal is to dramatically improve installation? Obviously the product could be installed previously and (as just stated) customers are not buying your product because they want to install it. So the business value of simplifying install is, um, well... not there. When you simplify install and the new product releases, you don't get to put a bullet down for something new that the customer can do. Sometimes this can be a hard sell, which results in products that are constantly adding new features but over time it gets harder and harder for customers to actually get value from the new features because they have trouble getting to them.
Talking about consumability changes the conversation. Improving consumability means less staffing is required for things that aren't adding business value, it means faster time to value, and it lowers the skills required to get things up and running... and maintain it afterwards. These are things that both planning teams and customers can get their head around. User experience isn't focused enough to make the same points.
I'm not sure whether "consumability" will make any headway outside of IBM, but I think there's a place for it.
Posted by Terry Bleizeffer at Wednesday, January 30, 2008 0 comments
Tags: consumability, user experience