Error Messages (Was: Hiding and Disabling Menu Items)

3 Jul 2008 - 10:23am
6 years ago
14 replies
1181 reads
Dan Saffer
2003

In fact, based on this conversation, I'm going to toss out one other
possible best practice:

The system should never present an error message to a user unless the
user has done everything right but the system itself cannot respond
correctly. Users should otherwise never be allowed to make "errors."

(Flickr, for instance, does this very well.)

Dan

Comments

3 Jul 2008 - 11:55am
Scott Berkun
2008

Way back when during my days at Microsoft, I worked on an OS project that
had the goal of eliminating all error messages in much the way you
suggested.

We found that in simple, webish, apps, this was easier to manage than say,
Excel or Word. In complex apps the amount of data entry or scripting like
functionality made it prohibitively expensive to handle all the error cases
well (or to eliminate the many gratutious error messages). Flickr is a great
example - there's a tiny amount of user data entry, and flickr does very
little with it - it's all meta data. Try to do the same with Quickbooks,
Filemaker, or even an E-mail program and it's much harder to pull off given
the # of non-trivial error cases. Not impossible, but more dev work
intensive than you'd think.

Error messages are popular simply because they are the cheapest interaction
a programmer has - it's much less work to handle users with errors than it
is to write code that gracefully resolves issues on its own.

So like in many cases, the question isn't as much about what the superior
design is, it's finding a way to make that superior design affordable to
build.

-Scott

----- Original Message -----
From: "Dan Saffer" <dan at odannyboy.com>
To: "IxDA Discuss" <discuss at ixda.org>
Sent: Thursday, July 03, 2008 7:23 AM
Subject: [IxDA Discuss] Error Messages (Was: Hiding and Disabling Menu
Items)

> In fact, based on this conversation, I'm going to toss out one other
> possible best practice:
>
> The system should never present an error message to a user unless the
> user has done everything right but the system itself cannot respond
> correctly. Users should otherwise never be allowed to make "errors."
>
> (Flickr, for instance, does this very well.)
>
> Dan
>
>
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help

3 Jul 2008 - 11:19am
Robert Hoekman, Jr.
2005

>
> The system should never present an error message to a user unless the user
> has done everything right but the system itself cannot respond correctly.
> Users should otherwise never be allowed to make "errors."
>

I second that. In fact, I preach it often.

-r-

3 Jul 2008 - 11:21am
Robert Hoekman, Jr.
2005

>
> We found that in simple, webish, apps, this was easier to manage than say,
> Excel or Word. In complex apps the amount of data entry or scripting like
> functionality made it prohibitively expensive to handle all the error cases
> well (or to eliminate the many gratutious error messages).

The hard part, I'm sure, is that removing errors means altering the task
flows that lead to them. In something as robust as Excel, that would be no
small feat. But wow, it would be so worth it!

-r-

3 Jul 2008 - 11:59am
Dan Saffer
2003

On Jul 3, 2008, at 9:55 AM, Scott Berkun wrote:

> Error messages are popular simply because they are the cheapest
> interaction a programmer has - it's much less work to handle users
> with errors than it is to write code that gracefully resolves issues
> on its own.
>
> So like in many cases, the question isn't as much about what the
> superior design is, it's finding a way to make that superior design
> affordable to build.

Clearly, this is a non-trivial task and more often than not a goal to
strive for in the hope of minimizing error messages.

I will say that this isn't only just an expedient method for
developers--I can tell when I'm getting lazy in my thinking when the
best I can offer is a pop-up error message. It can be an easy trap for
designers to fall into as well.

Dan

3 Jul 2008 - 3:06pm
Paul Eisen
2007

There's another way to approach this, that I think at least conceptually can help the designer make the right choices. We should all eradicate the word "error" from our design vocabularies.

I propose that the user NEVER makes errors. The user may do unexpected things, or provide unexpected input, or act in ways that the system is not sophisticated enough to deal with. Or that the sponsor of the system chooses not to deal with. But no error has occurred. Even a slip, where the user acts in a way contrary to their own intention, can be anticipated.

I personally think we should always avoid the word error in our artifacts. Most certainly in the UI. But even in our internal documentation and discussions. Calling these incidents "unexpected events" instead of "errors" leads to a totally different mind-set about how to deal with them. To begin: Let's start examining our expectations.

Paul Eisen
Principal User Experience Architect
tandemseven

-----Original Message-----
From: Dan Saffer
<snip>

The system should never present an error message to a user unless the
user has done everything right but the system itself cannot respond
correctly. Users should otherwise never be allowed to make "errors."

<snip>

________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help

3 Jul 2008 - 4:39pm
Robert Hoekman, Jr.
2005

>
> I propose that the user NEVER makes errors. The user may do unexpected
> things, or provide unexpected input, or act in ways that the system is not
> sophisticated enough to deal with. Or that the sponsor of the system chooses
> not to deal with. But no error has occurred.

Kinda touchy-feely, don't you think? Reminds me of those parents who
lavishly praise their kid for drawing a picture of a chicken that looks like
a horse.

Calling these incidents "unexpected events" instead of "errors" leads to a
> totally different mind-set about how to deal with them.

But people make mistakes. They accidentally click the A link when they meant
to click the B link. There's no shame in it. It's part of being a human
being — it's a given, and it's expected. We shouldn't try to deny this fact,
but rather pursue ways to prevent them with good design. Certainly easier
than trying to convince all the designers and developers in the world that
"users don't make mistakes".

Interestingly, I went to your site (www.tandemseven.com) just now and, after
looking around for a moment, clicked on the "personas" link. This link—the
very first one I clicked on the site—brought me to a page with absolutely no
information on it about personas, but rather a list of articles that
(apparently) contained the word. Articles with titles like "Portal
Solutions" and "About Us". The design led me to believe I'd get something
about personas, but I didn't. In fact, the text snippets on the landing page
didn't even contain the word "persona".

Was this an "unexpected event"?

Nah. I think one of us made a mistake. And in this case, I don't think it
was me.

We all make mistakes. It's a fact. Why deny it?

-r-

3 Jul 2008 - 5:59pm
Paul Eisen
2007

Robert Hoekman said:

Ø But people make mistakes.

Yes, they absolutely do. That's what I'm referring to when I mention, "Even a slip, where the user acts in a way contrary to their own intention, can be anticipated." But that doesn't mean that it serves us well as designers to call these "errors". As soon as we do that, we may create a mindset that limits our lateral thinking towards creative designs with elegant outcomes.

When the airline industry decided to address safety incidents by thinking of them as systems design issues rather than that recurring scapegoat called "human error, " the industry became much more effective at eliminating bad consequences resulting from unexpected incidents.

By the way, thanks for the feedback on the personas link. Sounds like a bad experience you had. We'll work on that.

Paul Eisen
Principal User Experience Architect
tandemseven

3 Jul 2008 - 6:21pm
Josh Powell
2008

Paul Eisen said:
When the airline industry decided to address safety incidents by thinking of
them as systems design issues rather than that recurring scapegoat called
"human error, " the industry became much more effective at eliminating bad
consequences resulting from unexpected incidents.

I think we agree on everything but some semantics. When I hear "user
error", I don't scapegoat the user, instead I focus on how that can be
prevented in the system design. What needs to happen is a change in
response on the part of designers who think that "user error" is really the
fault of the users and if that works in your organization by simply
restating "error" as "unexpected incident" then do it!

6 Jul 2008 - 6:23am
Anonymous

The other thing I'd add to this discussion is to consider the bigger
picture about what it tells you about your design if a particular
menu item is unavailable.

If it is obvious to your user why the item is unavailable, then you
probably have a good design. "Of course Save is grayed out right
now, since I have no file open."

If it is not obvious, then it may still be the right thing to grey it
out, but before going that route, the first thing should be to ask
yourself if this is telling you that you have the wrong design.

For example:

- Is it simply greyed out because it would take the programmers a
little longer to make it work in a particular scenario? Is that
scenario useful to your users?

- If it's greyed out because the item is only available in a
different mode, should you simply enable the menu item and have it
automatically switch to the other mode for the user? E.g. imagine a
special preview mode which doesn't allow editing. Question 1 might
be whether you should in fact allow editing in the preview mode. If
not, it's worth asking yourself if editing-related menu items should
be greyed out, or if they should be enabled and just take you out of
preview mode when selected. There, the right answer might be whether
the user would expect or be taken aback by it switching out of
preview mode.

- If it isn't simple and obvious for users to get to the state where
the menu item is enabled, does it mean your entire design is too
complex?

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=31032

6 Jul 2008 - 1:28pm
Suman Paul
2007

I with banking software.
For me things are bit different.
Inline error although is a god idea but most of the forms being large
and having constraint of showing maximum in one page kinda rules it
out.
Combine with it numerous validation error which might occur,
developers shy away from providing specific error messages and prefer
throwing generic and even in some cases technical error messages.

Any proven method how to show error in such situation?

Of course simplifying the form itself will solve lot of problem, but
yet we are left with lot of fields and more the field more the chance
of error.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=31032

7 Jul 2008 - 8:12am
AlokJain
2006

Suman,

1st part of the solution would ofcourse be how the forms are designed
- to prevent the error itself.

If the error does happen, here aret eh things we have done with long
forms:
1. Display error as user moves from one field to the next and not on
Submission. This reduces the number of errors users have to deal with
2. In our case we created a hierarchy of errors - for instance if a
password field was left blank - then we throw and error that it was
blank and not that it did not have minimum characters and it did not
use a number etc.. so only 1 error

- AJ

On Jul 6, 2008, at 11:28 AM, Suman Paul wrote:

> I with banking software.
> For me things are bit different.
> Inline error although is a god idea but most of the forms being large
> and having constraint of showing maximum in one page kinda rules it
> out.
> Combine with it numerous validation error which might occur,
> developers shy away from providing specific error messages and prefer
> throwing generic and even in some cases technical error messages.
>
> Any proven method how to show error in such situation?
>
> Of course simplifying the form itself will solve lot of problem, but
> yet we are left with lot of fields and more the field more the chance
> of error.
>
>
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> Posted from the new ixda.org
> http://www.ixda.org/discuss?post=31032
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help

7 Jul 2008 - 9:42am
Suman Paul
2007

Yes as suggested by AJ, progressive errors is a good idea.
But displaying errors when user tabs out ... how or where to show when you
have three column of fields.
Floating layers along with the field seems to be one solution.

But it might be a pain if user decides to go ahead with the error or warning
for later revision. Soon he might end up with bubbles all over the screen.
Extreme case but just in case.

Suman

On Mon, Jul 7, 2008 at 6:42 PM, Alok Jain <alok.ajain1 at gmail.com> wrote:

> Suman,
>
> 1st part of the solution would ofcourse be how the forms are designed - to
> prevent the error itself.
>
> If the error does happen, here aret eh things we have done with long forms:
> 1. Display error as user moves from one field to the next and not on
> Submission. This reduces the number of errors users have to deal with
> 2. In our case we created a hierarchy of errors - for instance if a
> password field was left blank - then we throw and error that it was blank
> and not that it did not have minimum characters and it did not use a number
> etc.. so only 1 error
>
> - AJ
>
> On Jul 6, 2008, at 11:28 AM, Suman Paul wrote:
>
> I with banking software.
>> For me things are bit different.
>> Inline error although is a god idea but most of the forms being large
>> and having constraint of showing maximum in one page kinda rules it
>> out.
>> Combine with it numerous validation error which might occur,
>> developers shy away from providing specific error messages and prefer
>> throwing generic and even in some cases technical error messages.
>>
>> Any proven method how to show error in such situation?
>>
>> Of course simplifying the form itself will solve lot of problem, but
>> yet we are left with lot of fields and more the field more the chance
>> of error.
>>
>>
>> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
>> Posted from the new ixda.org
>> http://www.ixda.org/discuss?post=31032
>>
>>
>> ________________________________________________________________
>> Welcome to the Interaction Design Association (IxDA)!
>> To post to this list ....... discuss at ixda.org
>> Unsubscribe ................ http://www.ixda.org/unsubscribe
>> List Guidelines ............ http://www.ixda.org/guidelines
>> List Help .................. http://www.ixda.org/help
>>
>
>

--
Thanks & Regards
Suman Paul

http://www.linkedin.com/in/skeep
http://picasaweb.google.co.uk/sumank.paul/

11 Jul 2008 - 7:27pm
Oleh Kovalchuke
2006

I disagree with your second point, AJ.

In an 'Error Correction Guidance' pattern I am working on at the moment, I
recommend writing brief guiding message, which addresses most common errors
*before* they occur.

So, in the example you have given, I would write:

"The password should be at least six characters long. It should include
numbers."

--
Oleh Kovalchuke
Interaction Design is design of time
http://www.tangospring.com/IxDtopicWhatIsInteractionDesign.htm

On Mon, Jul 7, 2008 at 8:12 AM, Alok Jain <alok.ajain1 at gmail.com> wrote:

> Suman,
>
> 1st part of the solution would ofcourse be how the forms are designed - to
> prevent the error itself.
>
> If the error does happen, here aret eh things we have done with long forms:
> 1. Display error as user moves from one field to the next and not on
> Submission. This reduces the number of errors users have to deal with
> 2. In our case we created a hierarchy of errors - for instance if a
> password field was left blank - then we throw and error that it was blank
> and not that it did not have minimum characters and it did not use a number
> etc.. so only 1 error
>
> - AJ

11 Jul 2008 - 7:35pm
Oleh Kovalchuke
2006

Otherwise I could have typed shorter password to satisfy your first guiding
message, tab out and be left thinking: "Now you are telling me!". The 'Error
Correction Guidance' pattern is in addition to a bunch of 'Error Prevention'
patterns, of course.

Oleh

On Fri, Jul 11, 2008 at 7:27 PM, Oleh Kovalchuke <tangospring at gmail.com>
wrote:

> I disagree with your second point, AJ.
>
> In an 'Error Correction Guidance' pattern I am working on at the moment, I
> recommend writing brief guiding message, which addresses most common errors
> *before* they occur.
>
> So, in the example you have given, I would write:
>
> "The password should be at least six characters long. It should include
> numbers."
>
> --
> Oleh Kovalchuke
> Interaction Design is design of time
> http://www.tangospring.com/IxDtopicWhatIsInteractionDesign.htm
>
>
> On Mon, Jul 7, 2008 at 8:12 AM, Alok Jain <alok.ajain1 at gmail.com> wrote:
>
>> Suman,
>>
>> 1st part of the solution would ofcourse be how the forms are designed - to
>> prevent the error itself.
>>
>> If the error does happen, here aret eh things we have done with long
>> forms:
>> 1. Display error as user moves from one field to the next and not on
>> Submission. This reduces the number of errors users have to deal with
>> 2. In our case we created a hierarchy of errors - for instance if a
>> password field was left blank - then we throw and error that it was blank
>> and not that it did not have minimum characters and it did not use a number
>> etc.. so only 1 error
>>
>> - AJ
>
>
>

Syndicate content Get the feed