So far, Palm nailed the product launch. But there’s one problem: when I tried to visit the palm.com site to learn more, it crashed my browser. So I restarted Firefox and tried again. Same result. One more time, I thought. And for a third time, the site took down Firefox. Given that every other site I use was working fine, I’m guessing the problem was on Palm’s side of things.

Amidst all the excitement, perhaps Palm neglected to test their updated site in other browsers besides Internet Explorer. After all, there’s a countless number of things to do right before a new product launch. But the more important the announcement and the more buzz it generates, the bigger the cost in terms of lost attention and earnings if your basic touch points aren’t working.

So when you write up your product launch plans, remember to test your website, phone system, and email to make sure things are mostly bug-free and your systems are ready to handle the load. Otherwise, your best-case scenario (where everyone wants to learn more) could turn into your worst nightmare (when bugs or capacity constraints prevent them from reaching you).

Having worked with some of the best web-based PBX systems, I can vouch that the tools for creating IVR menus have come a long way in recent years. From your web browser, you can record the voice prompts, determine what order they’re played in, assign actions to each number, etc. When you’re done, you can even view a visual tree with the various paths a caller can choose from. But things aren’t as simple as they seem. There’s no easy way to see what happens if someone enters an invalid option on a menu, or just holds the line without choosing anything. Sure, there are controls in the PBX software for this, but no easy way to test them.

Thus, creating a phone menu system where customers can’t get confused or stuck requires a lot of manual testing. You have to make up your own test procedures and update them every time the menu structure changes. Here’s how I would fix the problem: The PBX software already knows all the possible options, delays, and paths that a caller can use. Based on this, it could generate a testing checklist that includes each sequence of caller behaviors, and the expected result.

With this information, the user could print out the testing procedure, try each combination on the phone system, and make sure it checks out. Plus, since the testing list is generated dynamically, it’s easy to re-test the new cases after changes have been made. Even better, the test cases could be numbered and the results stored online for ease of reference. Granted, this isn’t a silver bullet, as someone still has to try the test cases (after all, there’s no other way to know if the right sound is playing or a message gets cut off). But this approach would certainly make it easier for PBX administrators to deliver error-free phone menus with less time and stress. Of course, that’s a great thing for the customers using those menus. They’ll run into fewer confusing options and dead ends, which means a greater chance of actually getting the info they need.

So, despite all their efforts to offer a consistent experience at each site, the chain apparently has different size serving equipment in some locations. If I had to guess, they probably have a stringent auditing process in place for things like store design, cleanliness, and quality of food. But when it comes to less obvious things like the exact amount of food that you get with each order, things might be a little less cut-and-dry. Perhaps store managers are free to purchase certain supplies from local vendors, so they don’t have to call the corporate office when they need more serving spoons, for instance. In any event, I don’t think anything devious is at hand, but rather, there’s a lack of controls over seemingly inconsequential aspects of the store experience.

Granted, this sort of variance may have little impact on customer satisfaction or profits. Heck, it took me a few months to notice the difference. But I wonder what other things might be escaping their usual quality controls. Now that I think about it, you tend to get less chicken, but more peppers, at one of the locations. The next time I’m at Chipotle, I’ll have to fill out a comment card, and see if they make any changes to get things consistent again. And for other businesses that are seeking consistency, my advice would be to look not only at the final product, but also at the tools and process that are being used to create it. Sometimes, even the size of a spoon can make all the difference.

Ok, so linking to other sites isn’t an exact science. But linking to your own pages should come pretty close. For the most part, this is also true when you link to things like search engines and mapping sites, since they’re quite good at making sure their pages keep working (even when the URL scheme changes). And that’s why it blows my mind that so many sites have broken links to these most basic of things. My personal favorite: A site provides a list of their retail stores or office locations with links to Google or Yahoo maps, but the webmaster uses an address that the destination site can’t understand. This makes the map link totally useless. And I’m willing to bet that this link never worked — they just never bothered to test it.

At the very least, broken links are frustrating to customers. And in many cases, they can have a direct, negative impact on revenues. After all, if people can’t locate your stores or add things to their shopping cart, they probably won’t be buying anything from you. So, when it comes to really important things like sign-up and contact forms, maps and directions to your stores or offices, and shopping cart and checkout features, do yourself a favor: Make sure the links actually work.

With this in mind, I was excited to hear that Opera Mini 4 had finished with beta testing, and is now a final release. I dutifully erased my old copies, downloaded the new one, and launched the program. After granting it network access when prompted, I expected to start browsing and checking out the new features. Instead, I was greeted with a network error, and the program said to go the Opera website for troubleshooting. The only option was to “Exit”. So I exited, removed the program from my handheld, and just gave up.

What’s my point here? In short, if you’ve managed to deliver a high-quality experience during your testing or beta phase, it’s even more important to ensure this carries over to your official release. Always re-test the popular uses of the product, make sure the old bugs from the beta phase remain solved, and even ask some beta testers to give your “release candidate” a try before you send it out to the wild.

With so many products carrying the “beta” label for months or years, saying something is “final” confers a lot of confidence in the product. I don’t know what sort of testing or quality assurance work Opera does for each new version, but something clearly got overlooked here. And since user expectations were set high based on the pre-release versions, these sort of mishaps in the final product hurt the company and its users that much more.

This sort of informal testing is pretty easy to do for the web and print, but a little more challenging for outdoor signs and consumer products. In the latter cases, my advice is to find real-life examples of another design that uses a similar approach. This is especially true for outdoor signage. The next time you’re passing a store or restaurant at night, think about which colors are the hardest-to-read at a distance. If you’re like me, you’ll be wondering why anyone uses blue letters, rather than higher-contrast options like white, yellow, or red.

While it’s nice to stay consistent with your corporate identity scheme, you should think twice about doing this if your corporate colors make the design hard-to-read. After all, if potential customers can’t find your restaurant or use your website even when they’re seeking it out by name, you’re leaving a lot of money on the table.

Here’s a case in point. I have a simple popcorn machine that works pretty well. You pour in the kernels, plug in the power cord, and wait for the popcorn to spill into the bowl. It really couldn’t be any easier to use, and I bet it did great in usability testing and focus groups. But after using it for awhile, I started to get really irritated by one simple omission: there’s no power switch. To turn it off, you have to yank the power cord from the wall. Since the machine gets really hot when you’re using it, this can be a tricky task to accomplish. In other words, it’s only after using the product for a few weeks that you really start to notice this simple but annoying design flaw.

So why don’t I contact the company and give them feedback? Like most product manufacturers, they would probably say that it’s working just like it was designed, so there’s nothing they can do. And since very few people would ever take the time to report such an issue, it would never reach the critical mass needed for the company’s product design team to fix it in the next version. And thus the cycle continues, and no power switch ever makes it into the product. Generally speaking, this scenario can affect anything from kitchen appliances to wool sweaters to web-based applications.

What’s the solution? I propose that you appoint some employees of your company to serve as official product users. Not just for an hour here or a day there in staged testing scenarios, but instead, using it regularly like your customers do. These employees would take the product home or use it at work, making it part of their routine. Then, when they come across issues and suggestions, they log them in a simple printed journal or an online tool. And of course, the company has to actually read and consider these suggestions on an ongoing basis. For the best results, the employees you select should come from different functional areas, ranging from product developers to marketing staff to customer support.

Granted, this approach might seem impossible when you’re talking about highly sophisticated or specialized products. In those cases, a product testing lab could be created so that staff members can at least get a general feeling for how customers use the product. In my popcorn machine example, let’s say that nobody in your company eats popcorn. Perhaps once a week, you could invite people from neighboring offices to stop by for free popcorn. Your employees would use the machine to make the popcorn, and then get feedback on the quality of the resulting product from your guests. Unlike a typical focus group or usability test, this would be repeated on a regular basis so that your employees become frequent users of the product — and start noticing the things that are often missed in one-off testing scenarios.