Amazon just sent me this email:

I am such a huge fan of [placeholder for winning team]. I've been rooting for them to go all the way, and seeing [placeholder for winning team] beat [placeholder for losing team]'s sorry ass was the highlight of my life. And as Amber will tell you, I'm always buying stuff with [placeholder for winning team]'s logo on it. I have a [placeholder for winning team] coffee mug, a [placeholder for winning team] sports jacket, and a [placeholder for winning team] license plate for my [placeholder for vehicle type]. [PLACEHOLDER FOR WINNING TEAM] RULES!

OK, seriously. I'm all for getting your act together in advance of a time-sensitive launch date - it's important to be prepared. But I'll bet you dollars to donuts that Amazon's email marketing platform made it a little to easy for someone to accidentally send this off to 5 million or so sports fans.

(As an aside - how do I know that Amazon uses some special software to send email marketing campaigns, and not just Microsoft Outlook? Because I'm assuming they aren't idiots. Any half-decent mail order company is going to use extensive email tracking techniques, including unique URLS for each recipient to aid in tracking pass-along emails, multiple messages per campaign, etc.)

Which brings us to the topic for the day: Dealing with Ooops.

All software, no matter how well defined, no matter how finely tuned, will eventually be used by someone who is careless, dangerous, ignorant, or all three. Whenever software is placed in a business-sensitive environment (that is, anywhere that its use or misuse will cost someone money), it is incumbent upon the designers of that software to anticipate and deal with mis-use.

There are a few ways most software companies deal with this fact:

1. Write an impossibly dense User Manual, which specifies in stupifying detail exactly how each feature should and shouldn't be used. For extra points, some custom software houses also document the business procedures (guilty!)
2. Interject an "Are You Sure" confirmation dialog each time the user attempts to do anything permanent.
3. Add magical workflow powder, provding the same obnoxious results as the previous option, but providing the added benefit of annoying at least two people.

The first two options are just laziness; rather than make the software work well, we just tell everyone how it's supposed to be used correctly. The last option is just bad business, and it borders on extortion - complex workflow apps are usually an excuse to bill more for software development or customization, and anyone whose worked on enough of these projects knows that most workflow rules are outdated by the time they get written down, much less built.

Most software just assumes that if someone goes to the trouble of clicking that button, then they must have meant to delete all of their customers' orders. After all, the confirmation message was perfectly clear.

The better solution is to make software which lets someone know exactly how many people are going to read that malformed email when they send it a day too early. Really, it's not as hard as it sounds. There are some simple steps:

• Watch how people use similar software, because that's how they're going to use yours. It doesn't matter how new or groundbreaking your software is. Once someone sits down in front of it and starts using it, they're going to try and relate it to something they already know.
• Whatch them use yours - you won't believe what they do with it. Once, I was testing a airline flight tracking website with someone who, though they claimed not to be very computer savvy, figured out how to access the raw data feed through the website and browse that for the flight information they wanted. It was actually awe-inspiring, but it also let us know that a "view all flights" feature would be helpful.
• Don't ask anyone what they want the software to do. Ask them what they want to do, and watch how they use the software to do it.