In doing some email maintenance today, I noticed that American Airlines didn’t have my current address information. I meandered over to their website to update it, and after submitting my changes, I got an error saying that they were unable to validate my apartment number. I tried everything I could to get it to accept my full address, but alas, the only success I found was when I submitted my address without an apartment number.

At that point, I noticed that despite me entering a 5-digit ZIP code, the confirmation page contained a ZIP+4. That means that they do some sort of back-end processing of the address to generate the nine-digit ZIP code; from the error I got with the inclusion of an apartment number, I assume that the back-end also includes some sort of verification that my address actually exists in a big property database, and that that database doesn’t recognize the fact that my building is divided into apartments. As a result of that deficiency, their database contains an incomplete address for me, which benefits nobody at all.

This all highlights the fact that, if you’re designing a web-based application and testing the data that people enter, you need to make sure that that test achieves its goal of providing better data without also setting up situations wherein the data becomes worse. That means one of two things: either your test needs to be 100% reliable, or you need to provide a method for people to clarify their entry when the test fails. And since the first option is nearly impossible to achieve, you’ll find that the second option is way more important.