However, if there’s only one Seattle, WA in the database and three different possible translations of WA, then that should have been caught in a design review. In this case, there should be logic (and additional data) that associates a province/state code with a specific country. So, if the country is US, the only translation for “WA” would be the correct one: Washington; if the country were Australia, then Western Austrailia would be the correct translation; etc.

I’ve seen things like this happen before, and there are several possible causes. One is that there was no review of the design actually done. Many times there is so much pressure to get a product deployed that shortcuts are taken that directly affect quality and usability. Peer reviews, walkthroughs, and field testing are the areas that typically get slighted, much to the detriment of the product’s users – regardless of whether those users are internal or external customers. Unfortunately, those are also the places where usability problems are most likely identified.

However, the more common problem in development organizations is one that no amount of peer reviews will solve, and that problem is having too limited a scope of who will be using the product and how it will be used. In the Hertz case, if the problem is that there are three “WA” possibilities, then the cause is thinking that only certain users would ever use the software: only people in the US. If only US airports are involved, then there’s only one translation for any of the standard USPS state codes. A design that works just fine for a single country, however, might not work so well in a global setting, which is a likely scenario for the Wanganui problem.

My company produces software for a specific vertical market, and most of the designers and developers expect the software to be used one way: the way they intended it to be used. What they have failed to realize is that the software may be used for purposes other than those intended purposes. Why? Because our customers have business functions that they need to accomplish, and some of them have been very creative in the ways they’ve used our software to do those functions. Sometimes it works well for them, sometimes it doesn’t.

So, to bridge that gap between the designers and the users, we are getting the users involved earlier in the software design process. Usability is also one of the criteria we use when reviewing a design. We are also putting more of an emphasis on developing good use cases and doing more prototyping than ever before. We seem to be getting better at usability, but our customers will be the ultimate judges of that.

In my organization, the usability testing and QA testing are both coordinated from within the R&D team. So we realized early on that we might (in fact, we would) uncover code/data problems during the usability testing. One of our process steps after every walkthrough and usability test is to enter defects found into the defect database. In this case, entering the “Wanganui” bug would (hopefully!) cause the software engineers to think about what other problems could occur involving the data encoding.

Interesting thought. But would a design review, code walkthrough, or careful QA testing actually have predictably caught this problem?

From my outside perspective, it looks like the problem is purely a data coding issue. Other cities, such as SFO or CHI don’t produce these problems.

It’s been awhile since I attended a design review or code walkthrough, but I’ve never seen one that inspected the data feeds.

I think there’s more to this problem than what our standard design practices can accomodate.

However, you ask how we might be addressing such problems thoroughly. To do so is the province of the development and quality assurance teams. They are the only ones with the mandate to catch such flaws. To attempt to be thorough in finding such problems during usability testing would consume more than the available usability resources.

Design reviews, code walkthroughs, and careful designing of QA tests based upon a thorough understanding of the software & database designs are more cost-effective ways to catch such issues.

OK, so maybe I have a not-so-firm grasp of the obvious.