Little Springs Design
is a user research and mobile design agency. We help wireless operators, manufacturers, and application & website providers with product and UI design, user research and strategy.Contact us today.
Learn about mobile
- Review our whole page on getting started in mobile design
- Take training from Little Springs
- Read our books or download one of our free whitepapers
- Read this blog or sign up for our almost-monthly newsletter
Recent blog entries
Top Posts for Today
- greatness and danger in police car computers (16 views)
- Yahoo! and Google mobile. Now slightly more mobile! (16 views)
- the future of the e-reader (15 views)
- Job posting: Interaction Designer (12 views)
- handbook of collaborative design (9 views)
- Mobile widgets: toy now, tool later (9 views)
- Are you wasting your mobile advertising dollars? (8 views)
- micropayments and so-called micropayments (7 views)
- first time use... over and over again (7 views)
- Paper or Plastic? e-readers vs mobiles vs book (7 views)
Blog topics
when you have an error, show it!
I have done a lot of work on interaction and interface design for security systems, government and corporate telecom management, and other complex stuff. A key attribute of each of these is that they were filled with error messages in the release before I got there.
I am generally against error messages, and even against help systems. Usually, you can design a successful, well-received interactive system to be clear enough it doesn't need any help documentation, and you can use clever design to avoid almost all explicit error conditions.
But sometimes they do happen, and then it's important that you not lie and confuse.
Every two week when I get paid I go to my bank's website, check out my accounts, balance the checkbook, transfer funds, pay bills and so on. This Friday when I went there, I couldn't get on (I have a password management scheme, so am sure I didn't forget it). I kept getting bad user/pass errors, then system unavailable messages when I tried to recover.
So I give up, assuming the system is broken or down for service. Coming back the next day, I encounter the same behavior except this time I get most of the way through the password reset (with lots of information keyed in) before it fails with a system-unavailable error.
So I call. And it's all lies. Somehow the system believed I had failed to enter the correct password three times in a row, and locked me out. The day before. Apparently, without an expiry time. Without calling, I guess you cannot get it unlocked. But, it never told me this in any way. So I sit there trying to fix the problem which cannot be fixed because I don't have all the information.
The lesson is: don't lie to your users. Provide enough information for users to understand the problem, and get solve it as quickly and painlessly as possible.
- If the user generated the error, tell them what they did wrong and how to fix it. Sure, if there is a security concern, you might need to be vague and not tell them which part of the username or password is bad. But do tell them there was an error in their entry, and they need to try agian.
- Enable re-entry. If the system is not locked or otherwise in fatal error mode, banish full screen messages. Clear messaging at the top of an entry screen is the right way to inform the user and let them try again without undue clicking or time wasted.
- Be clear about how to fix it. Yes, I said this already, but it's worth saying again. A common problem with bad authentication entry is the user not understanding in what format their username is. Tell them in labels, and again in error messaging that it's a unique value, or their phone number, or a complete email address, for example.
- Yes, even for deadbeats. If you have locked a user out for fraud, or lack of payment, you probably still want to talk to them. Maybe you got it wrong, or they are willing to pay. Always provide contact information, and tell them there's a way to fix their problem.
- If the user cannot fix the issue immediately, tell them. Lockout is a common issue, and you have to tell them to stop trying. If it's a matter of waiting for a timer, tell them the approximate time at least (security concerns often preclude you revealing the actual timer). Give alternative solution paths, like phone numbers or a store locator if you have customer service outlets.
- Don't be so specific you bore or frighten them. Outages or transient failures can, in a well-designed system, return any of dozens of codes. The user doesn't care or understand these, so compress them into a minimal number of useful categories. Keep in mind the principles above, and tell them how to get around it. If it's probably temporary, let them try again, or suggest they come back.
- Maintenance outages should be communicated in advance, and should prevent users from entering data that cannot be submitted. Plan carefully to not cut off users in the middle of transactions. And make sure your messaging tells them when it's supposed to come back online. Set aside a person on the team who is responsible for updating this message, and who is empowered to do so, in case the maintenance update fails, and the time needs to be updated. And don't lie; if it's all internal and has no clear user-facing improvements, don't say it's "to improve their shopping experience."
When designing your interfaces, respect and value your users, assume they don't work at your company, and you can avoid frustration, churn and expensive telephone calls.
No Comments »
No comments yet.
RSS feed for comments on this post.