Usability

Living With Bugs: How To Mitigate Usability Issues

Posted by Patrick Neeman at 9:00 am

I read this post at PinPoint Performance about usability issues that happen when good software goes buggy, and chuckled. Workarounds bad? Bugs bad? No kidding, Sherlock.

Releasing bug free software?

Uh, yeah, sure.

But I like to live in the real world too.

Today, we’re living in a “beta is acceptable” world. Requirements change. Wireframes aren’t updated. Changes aren’t communicated. Emails aren’t sent. Bugs are issued.

As much as I want to release products that are bug free, user friendly, and have every feature in the world working exactly as planned, I also like working realistic hours and shipping product on a timeline short of developing the space shuttle.

The point: most web applications aren’t life and death situations.

For this, there is an acceptable tolerance level. Users are willing to put up with a little discomfort if it means a fairly stable, better product; managing a realistic process means the difference between a good application with a few warts, and one that is completely broken with users that are leaving in droves.

As long as it doesn’t format their hard drive, they should be okay will a few application crashes.

Here’s a few things I’ve done to help mitigate issues in design and development:

  • Do hallway usability testing early on. Get some of your wireframes, show them to people, and ask them, “What do you expect this to do?” instead of telling them.
  • Site down with the developers and ask them to show you the system. It takes 30 minutes, and it means the world, because then you can clarify what you really meant with the spirit of the wireframes, and not the letter.
  • Do usability testing late in the process. Two weeks before you release, grab more people, walk them through several scenarios, and test for pass/fail. Figure out what can be fixed before the release with minor application changes or added help text, figure out what’s broken beyond fubar so you pull those features, and figure out what to have customer support tell the end users. If there’s a message there, the users will love you for it.
  • Schedule a second release after the first one. That’s why it’s called soft launch. For a second round of bug fixing, your users will appeciate going through a preview. If you do a search of all the marketing pushes occuring on hard release dates, it would be a good bet most of them failed because the applications failed to live up to expectations.
  • Talk to your users. Say you’re sorry. Say you’ll make it better. Listen and learn.

Similar Posts You Might Like

Trackback URL | Comments RSS Feed Both comments and pings are currently closed.

One Response to “Living With Bugs: How To Mitigate Usability Issues”

jbeller | September 10th, 2008 12:08

Patrick, thank you for referencing my recent blog post. I think I should clarify my stance regarding how bugs and workarounds should never be acceptable.

This is what happens when frustrations boil over to a blog. I probably shouldn’t have posted my frustrations because they largely had to do with a project I am working on. Unfortunately, I can’t reveal the client. Oddly enough many people I’m working with feel the same way about the situation and some things are just out of our control.

This particular project is a very simple application that queries a database. It’s hastily put together and users are expected to use it in their work. It’s far from perfect in its current state. Without considering HOW people work, the not ready for prime time application does more harm than good for the end-user because the bugs, errors and workarounds slow them down.

Do I expect bug-free applications? Absolutely not. Just like you I am a realist and your points in your post are quite good. It’s nearly impossible to be bug free, but what I am saying is if the business conditions allow, do the due diligence necessary to minimize the bugs, errors and usability issues as much as you can before release. This way you spend less time fixing problems. You also remove barriers to performance – which is what the application is supposed to do in the first place.

Hope this clears things up. I appreciate you taking me to task on this issue.