In this column, instead of talking about one of my usual topics—tactics to avoid errors—I’ll discuss how to work within constraints and pragmatically address real-world issues. During the software-development process, your team may ask you to design an error message. Annoying edge cases all too often pop up—usually too late in the process to fix the issue in any other way.
For starters, I never write what I’d call error messages. Admittedly, I occasionally use that term—in the same way I might use words such as sitemap—just at the beginning of a conversation to orient everyone to my process. Just as I did in the title of this column. But I then switch to a more meaningful term and get everyone to talk about exception messages. Read More
Since I wrote my article “Mobile Inline Form Validation” for UXmatters back in 2012, I have very rarely used any of those patterns in my own work. Recently, when I created a pattern library for mobile applications for a big, multinational, corporate client, I didn’t include any of those tips. Since the publication of that article, I have identified and begun to follow a few principles that are I hope more user centric.
Don’t See Users As the Source of Errors
If you design systems, you are familiar with constraints. For example, it is hard to add new fields to a database; mobile networks sometimes provide poor connectivity or have slow performance or high latency. Typically, system design takes such constraints—and, of course, costs—into account in determining what a team can build. Read More
Put a person and a computer together, and you have the possibility of an error. Put two computers together: more possibilities for error. People make mistakes and computers do unexpected things. We try to design out the errors as much as possible, but inevitably, we end up dealing with error messages. It’s easy to find plenty of recommendations about creating error messages. For example, Rhonda Bracey gave this succinct advice in her UXmatters article “Reviewing User Interfaces”:
“Good error messages tell users what went wrong—and possibly why—provide one or more solutions for fixing the error, and offer a set of buttons that relate directly to the next action a user should take.”—Rhonda Bracey