Yesterday Shane Schick at globeandmail posted an entry that I think is really missing the whole point of usability. When up to 75% of shopping carts are abandoned, when users with a need are given the money to buy and taken to online stores who offer that product and the results are only a 30% buy rate (i.e., the 7-11 milk experiment) , something is desparately wrong and it needs fixing!
That is what usability is about–getting software, products, and the web from this dismal, frustrating reality where it is now to a usable state, where things work like they are supposed to and are pleasant to use. When frustrating glitches (or funky animated graphics) don’t get in the way of you completing your task, that is a store you can shop at. If it was a pleasant experience, then you are more likely to shop there again–and tell your friends–and yes, that impacts the bottom line for any business.
When usability testing is ingrained in the development process and user research is just another step in everyone’s development process, then web sites and software will work like they’re supposed to and we will be at a state where usability isn’t a differentiator. We’re not there yet.
Shane’s four examples are all missing the point:
- First, Shane points to an Architecting for Happiness article from Michael Platt at Microsoft. Michael talks about how to convert a bad experience to a happy experience, and he brings up what sounds like a good idea–letting users collaborate to solve their own problems when confronted with a software error, rather than presenting them with a cryptic, frustrating error box. I like Michael’s idea, but I was a little dismayed when he said the UI people would “put it in a pretty box with a nice color and maybe a smiley face.” Um, last time I checked, that’s not what a good user experience designer would do. User experience design is about helping people efficiently complete their tasks in a satisfying way–it’s not about pretty boxes and smiley faces. If your UI people are doing that, then you should look at getting some better UI people. An error message should help the user solve the problem and get back to the task at hand. If collaborating with other users helps solve the problem, great, but don’t make users go to great lengths to finish their tasks because of a default in your software. Usability test that idea in a real-world situation and see how well it works for users.
- Shane then points to a commentary on Dennis McDonald’s blog. Shane’s title introducing Dennis’ commentary was “when user friendly gets too friendly”, and states that what vendors consider helpful might only frustrate users more, painting it as if usability actually introduces artifacts that frustrate users. He points to a quote from Dennis (taken out of context):
- Next, Shane points to an anti-usability blog entry from Todd Wilkens on Adaptive Path. Shane says, “He [Todd] likens the quest for better usability to giving someone a gold star for getting dressed in the morning.” Well, yeah, usability should be a basic given, but there are good reasons why bad software and web sites exist, and it is basically this: It’s very hard for humans to imagine not knowing something we know well. The creators of the software, product or web site know it inside out like the back of their hands. They know the inner workings and the exact placement of every button and feature, so it is almost impossible for them to anticipate what a user who is unfamiliar with the product or system will encounter. Usability methods–especially usability testing–ensure that you get that outside perspective and uncover those “sore thumbs” for users that the designers/developers literally cannot see. Usability is essential for exactly that reason–it points out the obvious, but invisible, glitches that are showstoppers for users.
- Now Shane points to an article from Scott Berkun and says, “those who can’t do, preach usability.” Whoa, whoa, whoa, Shane. Scott is pointing out a universal problem: that usability is brought in too late and that we need leaders who embrace usability in order for that to change. He is advocating that instead of complaining, usability people should find ways to change it. As Eric Schaffer points out in his book Institutionalization of Usability, we need people in management and executive leadership who recognize the value of usability, embrace it, and fold it into their natural business processes. The first step in establishing usability as a common practice in any organization is to gain executive sponsorship. Scott chose to take the management path himself, but I bet he has some good usability people working for him. Scott has some great points about how to get usability noticed, but not all usability people have the skills, charisma, or (most importantly) the desire to be managers. That doesn’t mean they can’t find someone who does and educate that person on the value of usability. It’s got nothing to do with the ability (or inability) to make things happen.
“if I’m busy and need to get as many tasks done as possible, I don’t want extraneous or distracting features in place that delay things or get in the way”
This is an argument FOR usability, not against it. What Dennis is saying is “if it helps the user get the job done, great–if not, don’t do it.” Exactly why the idea should be usability tested.