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.