Error messaging best practices

16 Jan 2004 - 11:16am
10 years ago
7 replies
4185 reads
Ryan Powell
2004

I'm looking for info on best practices / guidelines for error messaging
(for forms on the web)- both the content of the message and the way
errors are brought to the user's attention.

Does anyone know of any good sources? Or maybe just a site that has an
interesting solution?

Thanks,

Ryan Powell
HSBC
Chicago, IL

__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus

Comments

19 Jan 2004 - 8:39am
Carrie Ritch
2003

37signals has a wonderful resource on their site called Design not Found:
http://www.37signals.com/dnf/snapshots/index.php

Sort the list by Error Messages and you will find a lot of "don't do"
examples and some "do's". The bad examples are very informative as to what
you should include in error messages.

good luck,
carrie

-----Original Message-----
From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesign
ers.com]On Behalf Of Ryan Powell
Sent: Friday, January 16, 2004 11:16 AM
To: discuss-interactiondesigners.com at lists.interactiondesigners.com
Subject: [ID Discuss] Error messaging best practices

I'm looking for info on best practices / guidelines for error messaging
(for forms on the web)- both the content of the message and the way
errors are brought to the user's attention.

Does anyone know of any good sources? Or maybe just a site that has an
interesting solution?

Thanks,

Ryan Powell
HSBC
Chicago, IL

__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus
_______________________________________________
Interaction Design Discussion List
discuss at interactiondesigners.com
--
to change your options (unsubscribe or set digest):
http://discuss.interactiondesigners.com
--
Questions: lists at interactiondesigners.com
--
Announcement Online List (discussion list members get announcements already)
http://interactiondesigners.com/announceList/
--
http://interactiondesigners.com/

19 Jan 2004 - 10:51am
Todd Warfel
2003

Ryan,

In addition to the 37Signals DNF resource, a few things we've learned
over the years...

1. Error prevention is better than messages (e.g. try to format things
like date fields for the user once they submit them instead of making
them submit in MM/DD/YYYY or similar format)
2. Error messages should use plain english, not cryptic error codes,
which mean nothing to users
3. Error messages should be visually clear (often this means brightly
coloured, bold, larger text, with an error icon (triangle with ! in
it), highlighted background colour) at the top of the page
4. If there's more than one error message, use bullets (li) to ensure
the user knows that there's more than one item that needs to be
addressed
5. Clearly tell the user where the error occurred at the top of the
page, then highlight the offending field in the page (e.g. "Your credit
card number is not valid. Please check to make sure you entered the
correct account number." Then at the CC field, "Please verify the
account number.")
6. Maintain the users information that was entered into the form -
don't make them reenter the information.
7. Return the user to the same page, don't make them "go back" to a
page to fix the errors.

On Jan 16, 2004, at 11:16 AM, Ryan Powell wrote:

> I'm looking for info on best practices / guidelines for error messaging
> (for forms on the web)- both the content of the message and the way
> errors are brought to the user's attention.
>
> Does anyone know of any good sources? Or maybe just a site that has an
> interesting solution?
>
> Thanks,
>
> Ryan Powell
> HSBC
> Chicago, IL

Cheers!

Todd R. Warfel
User Experience Architect
MessageFirst | making products easier to use
--------------------------------------
Contact Info
voice: (607) 339-9640
email: twarfel at messagefirst.com
web: www.messagefirst.com
aim: twarfel at mac.com
--------------------------------------
In theory, theory and practice are the same.
In practice, they are not.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 2226 bytes
Desc: not available
Url : http://lists.interactiondesigners.com/private.cgi/discuss-interactiondesigners.com/attachments/20040119/55196524/attachment.bin

19 Jan 2004 - 3:40am
jstanford
2003

We've found an effective way of error messaging on the web through
testing and many years of experience which we tend to use on all of our
web design projects that involve forms. It has several parts:

1) Mark all the fields that have an error in a color (like bold red)

2) At the top of the page, put an eyecatching icon indicating an error
(preferably something friendly) and intro text such as "Some information
below is missing or incorrect. Please look at the item(s) marked in red
and enter the requested information."

3) Follow the intro message described in point 2 above with a bulleted
list of the fields that have a problem and a simple explanation of the
problem. For example:

Some information below is missing or incorrect. Please look at the
item(s) marked in red and enter the requested information.
- Resource: Enter a resource name that has not previously been used. The
resource name you entered is already used by another resource.
- Resource type: Select a resource type.

- Julie Stanford
________________________________________________________________________
__

Julie Stanford
Principal
julie at slicedbreaddesign.com
www.slicedbreaddesign.com <http://www.slicedbreaddesign.com/>
<http://www.slicedbreaddesign.com/>
phone: 650-625-1925
mobile: 650-799-7225
fax: 240-525-1315

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.interactiondesigners.com/private.cgi/discuss-interactiondesigners.com/attachments/20040119/1564fd6b/attachment.html

19 Jan 2004 - 11:35am
Todd Warfel
2003

This sounds pretty good. The only thing I'd suggest is not to say
"marked in red" as that doesn't pass the colour blind test. 508 is
something we also have to consider.

On Jan 19, 2004, at 3:40 AM, Julie Stanford wrote:

> We've found an effective way of error messaging on the web through
> testing and many years of experience which we tend to use on all of
> our web design projects that involve forms. It has several parts:
>
> 1) Mark all the fields that have an error in a color (like bold red)
>
> 2) At the top of the page, put an eyecatching icon indicating an error
> (preferably something friendly) and intro text such as "Some
> information below is missing or incorrect. Please look at the item(s)
> marked in red and enter the requested information."
>
> 3) Follow the intro message described in point 2 above with a bulleted
> list of the fields that have a problem and a simple explanation of the
> problem. For example:
>
> Some information below is missing or incorrect. Please look at the
> item(s) marked in red and enter the requested information.
> - Resource: Enter a resource name that has not previously been used.
> The resource name you entered is already used by another resource.
> - Resource type: Select a resource type.
>  
> - Julie Stanford
> _______________________________________________________________________
> ___
>
> Julie Stanford                                                  
> Principal
> julie at slicedbreaddesign.com                           www.slicedbreadde
> sign.com
>  
> phone:   650-625-1925
> mobile:  650-799-7225
> fax:       240-525-1315
>
>
>
>
>  
> _______________________________________________
> Interaction Design Discussion List
> discuss at interactiondesigners.com
> --
> to change your options (unsubscribe or set digest):
> http://discuss.interactiondesigners.com
> --
> Questions: lists at interactiondesigners.com
> --
> Announcement Online List (discussion list members get announcements
> already)
> http://interactiondesigners.com/announceList/
> --
> http://interactiondesigners.com/

Cheers!

Todd R. Warfel
User Experience Architect
MessageFirst | making products easier to use
--------------------------------------
Contact Info
voice: (607) 339-9640
email: twarfel at messagefirst.com
web: www.messagefirst.com
aim: twarfel at mac.com
--------------------------------------
In theory, theory and practice are the same.
In practice, they are not.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 3684 bytes
Desc: not available
Url : http://lists.interactiondesigners.com/private.cgi/discuss-interactiondesigners.com/attachments/20040119/fae0e2a3/attachment.bin

19 Jan 2004 - 12:03pm
Robert Reimann
2003

Of course, the best design tip regarding error messages
is to design your product or system so that they aren't
necessary. Not always possible (especially on the web)
in all cases, but it's a goal to shoot for. The Amazon
"Fuzzy Search" example (listed under Search Results, not
Error Messages) on the 37signals site is a good example
of this kind of thinking.

Robert.

---

Robert Reimann
Manager, User Interface Design
Bose Design Center

-----Original Message-----
From: Carrie Ritch [mailto:critch at rochester.rr.com]
Sent: Monday, January 19, 2004 8:40 AM
To: discuss-interactiondesigners.com at lists.interactiondesigners.com
Subject: RE: [ID Discuss] Error messaging best practices

37signals has a wonderful resource on their site called Design not Found:
http://www.37signals.com/dnf/snapshots/index.php

Sort the list by Error Messages and you will find a lot of "don't do"
examples and some "do's". The bad examples are very informative as to what
you should include in error messages.

good luck,
carrie

-----Original Message-----
From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesign
ers.com]On Behalf Of Ryan Powell
Sent: Friday, January 16, 2004 11:16 AM
To: discuss-interactiondesigners.com at lists.interactiondesigners.com
Subject: [ID Discuss] Error messaging best practices

I'm looking for info on best practices / guidelines for error messaging (for
forms on the web)- both the content of the message and the way errors are
brought to the user's attention.

Does anyone know of any good sources? Or maybe just a site that has an
interesting solution?

Thanks,

Ryan Powell
HSBC
Chicago, IL

__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus
_______________________________________________
Interaction Design Discussion List discuss at interactiondesigners.com
--
to change your options (unsubscribe or set digest):
http://discuss.interactiondesigners.com
--
Questions: lists at interactiondesigners.com
--
Announcement Online List (discussion list members get announcements already)
http://interactiondesigners.com/announceList/
--
http://interactiondesigners.com/

_______________________________________________
Interaction Design Discussion List discuss at interactiondesigners.com
--
to change your options (unsubscribe or set digest):
http://discuss.interactiondesigners.com
--
Questions: lists at interactiondesigners.com
--
Announcement Online List (discussion list members get announcements already)
http://interactiondesigners.com/announceList/
--
http://interactiondesigners.com/

19 Jan 2004 - 9:18pm
Elizabeth Bacon
2003

Hello Nathan, et al.

I think there's another way to conceive the guideline that Anirudha laid out
("Save should save the user work, not necessarily what the computer thinks
is complete.") As I understood this guideline, it's not so much that the
system has to constantly store data so that people's random actions can be
handled appropriately (which is indeed a good thing when it can be managed
transparently), but that chiding a person for an incomplete form should be
reserved for the absolutely final step in which that data is required.
Preventing forward progress until every required field is complete on a
transactional web site is going to have to occur at some point, obviously,
but this can be experienced in a goal-directed way so that people recognize
that moment as a necessity to serve themselves. I'd say anecdotally that
more e-commerce web sites are implementing their forms in this less rigid
way, especially in the area of profiles and accounts.

Another good place for error message guidelines is Apple's Aqua Human
Interface document. Handled in terms of dialog construction, it describes an
approach where the dialog box is in fact supporting a dialog between the
system and the user. The system takes an educated guess as to the cause of
the error and poses a question to the user, and the action button labels are
different responses. Supporting text also helps to clarify the issue, but
essentially the error can usually be resolved with a glance at the highly
readable headline + icon, and/or a quick scan of the button options.

Cheers,
EB

-----Original Message-----
From: Nathan Moody [mailto:nathan at atomick.net]
Sent: Friday, January 16, 2004 11:17 PM
To: discuss at interactiondesigners.com
Subject: Re: [ID Discuss] OK/Cancel buttons: no mnemonic; why?

Hi there - new to the group, wanted to share on this topic...

On Jan 16, 2004, at 7:44 PM, Anirudha Joshi wrote:
> 'Save' should save the user work, not necessarily what the computer
> thinks is complete.

As a designer and user advocate, I couldn't agree more. However, I've
found that in the web app/rich internet app/x-internet (ad extreme
nauseum) world, we sometimes have to break that rule in order to
benefit user experience.

As counter-intuitive as that seems, it's an issue of server
communication; in a local app, communicating with a filesystem or OS
can be very quick, so every single field entry (or even keystroke) can
be stored in pretty much real-time. Save buttons aren't always needed
in some cases.

However, the challenge of complex forms with many data fields can make
this an incredibly interruptive experience for a user in a web-enabled
world...are we really going to try to send packets of data for every
keystroke? Is a server listening to every user's keystrokes, or for
every tab key to send a field, monitoring hundreds (thousands?) of
potential concurrent users? How will that impact both client and server
side performance? Not only can this introduce back-end problems (and
thereby raise deployment costs), but this can also bog down a client
machine fiercely, no matter what their connection speed is...the
browser becomes a bottleneck at that point.

So, basically we've been sometimes forced to split the needs of the
technical requirements with those of the user, and make sure that we
collect just the right amount of information in each step, and then
shuttle that to the server in one chunk so as to create as little user
waiting as possible, thereby attempting to IMPROVE user experience
through the illusion of high performance per form segment or per wizard
step. Of course, the proof's in how one divides up a complex process
into small, tasty, digestible chunks...

So, totally agreeing on this point, but sharing some experiences where
we found another scenario that trumped this guideline! ;-)

Best,
-Nathan Moody
Director of Interactive Media, Fluid, Inc. (www.fluid.com)
Creative Director, Atomick Industries (www.atomick.net)

_______________________________________________
Interaction Design Discussion List
discuss at interactiondesigners.com
--
to change your options (unsubscribe or set digest):
http://discuss.interactiondesigners.com
--
Questions: lists at interactiondesigners.com
--
Announcement Online List (discussion list members get announcements already)
http://interactiondesigners.com/announceList/
--
http://interactiondesigners.com/

19 Jan 2004 - 11:31am
jstanford
2003

We've found an effective way of error messaging on the web through
testing and many years of experience which we tend to use on all of our
web design projects that involve forms. It has several parts:

1) Mark all the fields that have an error in a color (like bold red)

2) At the top of the page, put an eyecatching icon indicating an error
(preferably something friendly) and intro text such as "Some information
below is missing or incorrect. Please look at the item(s) marked in red
and enter the requested information."

3) Follow the intro message described in point 2 above with a bulleted
list of the fields that have a problem and a simple explanation of the
problem. For example:

Some information below is missing or incorrect. Please look at the
item(s) marked in red and enter the requested information.
- Resource: Enter a resource name that has not previously been used. The
resource name you entered is already used by another resource.
- Resource type: Select a resource type.

- Julie Stanford
________________________________________________________________________
__

Julie Stanford
Principal
julie at slicedbreaddesign.com
www.slicedbreaddesign.com <http://www.slicedbreaddesign.com/>
<http://www.slicedbreaddesign.com/>
phone: 650-625-1925
mobile: 650-799-7225
fax: 240-525-1315

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.interactiondesigners.com/private.cgi/discuss-interactiondesigners.com/attachments/20040119/2c3b8db5/attachment-0001.html

Syndicate content Get the feed