In user testing sessions I often see websites or applications that solicit user input but don’t adequately communicate the input rules. This occurs most commonly in web forms that don’t specify up front which fields are required, but there are plenty of other examples to be found. Not surprisingly many users have a tendency to fill out as few fields as they feel they must, for a variety of reasons.
When it comes to forms, users typically skip entering information and trigger errors for one or more of the following reasons:
- They skip fields to save time, assuming the information isn’t necessary/required
- They leave out information because they don’t entirely trust the website’s security or privacy
- They don’t clearly understand what the system expects from them
It’s for these reasons that failing to set the rules upfront in any kind of interaction is a sure-fire recipe for a problem. One example that comes to mind is PayPal. Sending money from the PayPal website involves filling out a form that requires the user’s home phone number – but the field isn’t clearly labeled as required. If the user declines to enter a phone number then then website displays an error message indicating that the phone number is required. This is a bit of an “error trap” since there’s no indication ahead of time that the information is required – and since it’s personal information that users might understandably wish to keep private if they can. I’ve seen quite a lot of user testing respondents get ticked off when they discovered input rules only after breaking them. So it makes sense to clearly communicate the rules upfront and set expectations.
In the case of required fields the solution to the problem is straightforward: clearly indicate which fields are required for example by placing a red asterisk next to each required field, and a legend atop the field to the effect of “* = required information”.
Similarly, fields that require a specific type of information or format should also clearly indicate what’s expected. For example, if only numbers are accepted in a field this should be clearly indicated with a text hint or other label (“numbers only”). Using simple examples often helps, e.g. – “numbers only (12345)”.
Communicating the rules is also important after a process is completed. I recently conducted an online funds transfer using a large banking website. Once I’d completed the transaction I was presented with a lengthy disclaimer on the confirmation page that ended with the following statement:
“You will not be notified in the event of a failed transfer.”
Let’s set aside the question of why the bank wouldn’t want to inform me if an important process had failed. What I find interesting here is that this fairly important rule was stated at the end of a paragraph, and was presented in standard-sized black text with no particular visual cues that suggested it had any special importance. Consider for a moment all the adverse effects that could occur as a result of a user not knowing that an important money transfer hadn’t taken place as expected. It’s not pretty.
Regardless of the reason for not notifying, the ideal (and obvious) solution here would be to inform customers if an electronic transfer fails. There may be specific technical reasons this isn’t possible, so the next line of defense should be a much stronger indication of the policy – presented in a place and manner that’s difficult to overlook. For example:
Here the notification message is presented with an eye-catching background color, and the message includes specific instructions about checking to ensure the transfer takes place as scheduled. A “learn more” link provides a way to present additional details (such as the reasons for the no-notification policy) if the user wishes to see it. This type of approach more effectively sets expectations and increases the chances that users would be able to make arrangements if their transaction wasn’t completed as expected.
Photo credit: faeryboots. Creative Commons licensed.
Related posts: