My recent stumbles on a department store credit card web site provide an excellent example of the difference between checking software versus really testing it.
On Feb. 15 my wife and I notice that the bill for our new credit card is due - on Feb. 14. Bummer. We had just gotten the card (in order to get a discount on some bedding and flatware) and so it isn't yet part of our bill-paying routine, nor have we set it up as a vendor in our bank's online bill payment system. But I notice the bill says we can pay online at their website. Great! Off to their website, where I see I must first register my account.
Online registration asks for my account number. I enter the account number exactly as displayed on the bill, a series of numbers and dashes, in an unstructured text box. I also fill in the other required fields (name, address, etc.). Submit.
The form redisplays, a red box at the top warning "Please enter all required information", and a red mark denotes the account number field.
I recheck, and the information I entered matches the bill exactly. Having been down a similar road before, I try removing the dashes from the Account Number. Submit. Success!
Issue #1: Inflexible data field, requires format inconsistent with that supplied to user.
Yes, this feature worked, within a narrowly defined scope, so technically no bug. But what a poor user experience! (Warning: Design rant!) How many customers has this form annoyed? How many had to call the service line for live help? Think of what a couple of hours scrimped on development cost in the long run.
How might this form been improved? Here are some possibilities:
- Accept the format shown on the bill. Did the developer look at a bill, the thing most customers would be registering from?
- If they really needed only numbers, how about noting that on the form? Beside the label "Account Number" add the clarifying text "(numerals only, no dashes)".
- Present the field entry boxes in a way to clarify the format. Perhaps a series of single character linked text boxes, with hyphens displayed where appropriate.
- When parsing the field entry, recognize the unacceptable characters and generate a helpful message. For example, "numeric digits only please, no hyphens".
- Or how about taking a couple more hours of programming to parse the field contents, eat any white space (which might include spaces or dashes), and display the data back in the field, with the desired formatting.
Moving on, now that I successfully registered, I want to pay my bill. The layout is clear, the options appropriate. I pick the payment amount. Now for the payment date. Remember, I am already a day late. My choices are:
- Today (2/15/2012)
- Due date (2/14/2012)
- Another date (chooser widget to select)
#Issue 2: Why am I being offered yesterday as an option?
I check "Today" and OK the form. I get a Javascript pop-up "Warning: Selected Date is past the Due Date, which may incur a penalty. Consider an earlier payment date."
#Issue 3: What choice do I have? Can they turn back time?
I decide to try their little wormhole, and choose "Due date" (i.e., yesterday). Submit. Accepted without warning.
#Issue 4: Why does it allow (even encourage!) me to pick a date in the past?
So I have submitted with a payment date of yesterday. No error, but no confirmation either. I see the account summary page, with no indication of a payment. Is it scheduled? Or maybe in process?
I risk a double payment by trying again. Same result.
So I try a third time, selecting "Today" and pushing through the warning about late payments.
Success, with confirmation. That means the first two attempts did fail!
#Issue 5: Silent failure on payment dates in the past.
Let's review. The website offered a rich set of useful features, which all worked correctly under ideal circumstances. Yessir, someone checked that functionality!
But a series of reasonable though non-optimal inputs caused a number of unacceptable reactions. No, it does not appear anyone really tested this.
