Showing posts with label design. Show all posts
Showing posts with label design. Show all posts

Friday, August 17, 2007

When good design means bad usability

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.

Wednesday, August 1, 2007

Supporting browser back buttons in web apps

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.