Post image for Watch out! Default values ahead…

Watch out! Default values ahead…

by Mike B. Fisher on March 12, 2009

Quick summary: Default values are often helpful – but there are hidden downsides that can cause unnecessary user frustration.

Presenting users with default values in an interface is often a good way to save time and provide input suggestions. But like so many practices in interface design it can cause problems if you’re not mindful of the rules you apply.

Here’s an example: I recently initiated an electronic transfer of funds from a Washington Mutual checking account. While I was defining the transfer parameters (amount, to/from accounts, date, etc.) the website displayed a default date value for the effective transfer date. I had requested the transfer on a Friday, and the date selection defaulted to the following Monday – indicating that Monday was the earliest  date on which the transfer could occur. So far so good. But I was surprised to see the following message when I attempted to finalize the process:

“External transfers are not processed on Saturdays or the day before holidays. Please enter a different date.”

It appears that I triggered an error condition simply by accepting the date that the system had “suggested” since it happened to fall just before a holiday. If WaMu’s system is capable of limiting my choices based on a set of date-based rules, shouldn’t it also be capable of selecting a default value that doesn’t violate its own rules?

What’s that you say – you’d prefer a metaphor? I’d be glad to.

The metaphor

Suppose you’re dining at a restaurant and have the following conversation with your waiter:

“Welcome to Le Food Extraordinaire. May I suggest one of our specials?”

“Sure, what’s good?.”

“I recommend the lobster bisque today. It is made from only the choicest lobsters, hand selected by a panel of experts.”

“Sounds great, I’ll have that.”

“You’ve made a mistake, monsieur; we don’t serve the lobster bisque before 6pm, and I see that presently it is only noon. Perhaps you would like the duck a l’orange? It’s – how do you say in English – to die for.”

“Okay, I’ll have the duck a l’orange then.”

“No, it is not offered on Fridays; surely monsieur is aware that today is Friday?”

And so on. The point here is that providing a suggestion or default value makes little sense if the system won’t accept it.

A better approach

Going back to my original example, a better approach would of course have been for the system to propose the soonest valid and available transfer date, but also to display a disclaimer if the date was more than a couple of days into the future. For example, if it were Friday and the soonest transfer were the following Wednesday the system could provide a message along the lines of:

“Your transfer is scheduled for the next available date, which is Wednesday December 26, 2008. (why is this the next available date?)”

The “why is this the next available date?” text would then link to (or trigger a pop-up displaying) a brief explanation of the transfer policy with respect to holidays and weekends. In other words, the system should:

  • Only select default values that are valid according to the system and business rules
  • Anticipate that if a default value – in this example the transfer date – will be different from the user’s expectation then he or she is likely to wonder why
  • Give the user a means to understand the “why” of the default value

Preventing users from encountering errors – especially error “traps” like the one described above – and providing clear and concise explanations of the applicable rules – will result in less confusion and frustration, and will increase the chances that users will move through a desired transaction quickly and with minimal difficulty.


Photo credit: SideLong. Creative Commons licensed.

Be Sociable, Share!

Related posts:

  1. Communicate the rules

Leave a Comment

Previous post:

Next post: