The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Users don't read what's in front of them

My day job (Tuesday through Thursday) has me working on web-based systems for a large government organisation. Hundreds and even thousands of users of very limited computer experience must use our systems on a daily basis. It is quite interesting to notice the usage habits that these sorts of people display, as they can point out deficiencies in systems that are not readily apparent to more experienced computer users.

What I'm talking about in this particular case is the fact that if there is too much writing on the screen, or if it is too small, or out of the way, or even the wrong colour, it gets ignored.

One of our screens requires that users enter in a set of data. This data must adhere to certain rules, which are explained clearly on the page, or the data is not permanently saved. That is, if the exit and return to the screen, their data will not be there if it did not validate correctly when they initially went to save it. In other words, we're operating under the rules of a standard web-based form whereby if there's an error, we alert the user to the error and refuse to save it until they correct the data.

Turns out our error messages were not obvious enough. I had the error message showing up in bold red at the top of the form, and the data field being highlighted in red as well. This would normally work if there were a next step that the user was prevented from accessing until the data was correct, but in this case, there is just one screen to enter the data. What many users were doing was going through, entering all of their data, pressing save, then leaving the screen. Our nice bold red error messages were being ignored, then we were getting abusive error reports from the users who were claiming the system was broken because when they came back, their data was gone.

I've now changed the error message so that not only is it bold red, but it's a bigger font size, sits in a big yellow box and is surrounded by a thick red border. It is now much more blatant and "in your face". In addition, when the data is saved, if the user has filled out all fields and the data does not meet certain criteria, I've included a javascript message box that they must click "OK" on before they can progress. The alert box warns them that their data has not been saved. I'm hoping this will rectify the problem.

The moral of the story? Make things bleedingly obvious. Don't let the user do anything wrong if they're not forced upon the realisation that they've made an error and given instructions on how to rectify it. They won't go looking for the answer, they'll just give up in frustration.
Nathan Ridley [View My Blog!] Send private email
Monday, October 10, 2005
 
 
Sometimes even the bleeding obvious isn't enough.
One system I worked had a customer ID combo box. The user could select an existing ID or enter a new one. If they entered an unrecognised customer number and attempt to move away from the screen they were prompted with a message that stated: The customer number you entered is not in the system. Would you like to add this as a new customer (Yes or Cancel).

If they chose Yes a separate modal dialog appear where they could the details of this new customer.

They chose Cancel as they realised they mistyped the customer number and wanted to correct it.

One user, rather than reading the message, simply hit ESC and tried to leave the screen. Again they were prompted. Again they hit ESC. A dozen ESC hits later they called Help Desk. At no time did they ever read the message (which they freely admitted).

While I recognise and accept that it is our job to try to make systems more intuitive, I'm stumped on how to handle users who don't make the effort to read an instruction (I can fully appreciate if the instruction is ambiguous).

Does the same defence apply for the speeding motorist who informs the traffic cop that it's his fault they didn't bother reading the speed limit signs they passed?
Marcus from Melbourne
Monday, October 10, 2005
 
 
There's probably a limit. I've heard various stories of user stupidity from within the organisation I work for, and some of them boggle the mind. I think that all you can really do is throw a blatant brick wall in the face of such people and prevent them from proceeding.

On the other hand, sometimes you can get the message through simply by adjusting the way you actually present the information to the user. Colours, font sizes, etc. can make a a difference.
Nathan Ridley [View My Blog!] Send private email
Monday, October 10, 2005
 
 
Yes, sometimes users are just stupid.

However, if MOST users will react the same stupid way, then they are not the problem, the program is the problem.  Because the users are, in that case, acting predictibly.
Mr. Analogy {Shrinkwrap µISV} Send private email
Tuesday, October 11, 2005
 
 
Secure
Tuesday, October 11, 2005
 
 
> One user, rather than reading the message, simply hit ESC and tried to leave the screen... A dozen ESC hits later they called Help Desk.

Well that's understandable isn't it?  ESC usually acts as the shortcut for Cancel no? So maybe (s)he was used to it and just thought the cancel option/button wasn't working?

Or are you saying they could cancel but not leave the "screen" without removing the invalid customer code?

Tuesday, October 11, 2005
 
 
Sounds like a design deficiency upon your part.  It makes no sense to allow the user to navigate away from a screen, and not save it.

If you can validate the content and mark those bits that are missing, you can stop the user moving away too.
new nick, new rep
Tuesday, October 11, 2005
 
 
I work for an ISP on helpdesk. We have a webmail login screen that says "Enter your username" followed by a text box and then in bold writing right next to it "NOT your full email address". We still get heaps of calls from people entering their full email address.
Daniel S
Tuesday, October 11, 2005
 
 
Daniel S.,

If the webmail login screen is intelligent enough to know that the user entered their full email address instead of just the username, then it should just strip the spurious characters from the entered text and (quietly) proceed with the login...

OP: Why not use a pop-up modal dialog box to display the error message? That's about as "in your face" as you can get...
Master of the Obvious
Tuesday, October 11, 2005
 
 
Likely the webmail screen simply checks to see if the username is valid - without checking the "special case where it's an email address".

ie, user enters X.

The system then goes to the authentication module and asks "Is X valid?"

The authentication module then responds "No" if the username is not already in the system. For example, I might've mixed up the spelling, or used the wrong spellings, or even typed in an email address!

Checking for email addresses is actually quite complicated, so imho, just saying that you only want the _username_, not the full email address, is sufficient.

imho, minimal user training can go a long way - if things don't seem to work, READ THE ERROR MESSAGES!
Arafangion Send private email
Tuesday, October 11, 2005
 
 
You can extract usernames from full email addresses with a regular expression:
"/^([^@]+)(@.*)$/"

You can try to login with the supplied string. If it fails, you can use the RE above to get just the username. If this is a non-empty string, try to login with that. If this login fails, then there's a good chance the username is invalid.

Regarding the original point, users don't read what's in front of them because a lot of the time it's techno-babble they can't decipher anyway. Programmers are generally poor at communicating technical information to non-technical people. Most error messages and on screen instructions, unfortunately, are written by the programmers. Users click on things or enter text based on a quick visual scan of the form/window. They get conditioned to click/enter things that are similar to things they already know.  For instance, most Windows applications ask something like, "File has been modified, do you wish to save?" when exiting an application where changes haven't been committed, providing "Yes" and "No" buttons. Once users get the gist of this dialog, they click on "Yes" without reading the message. Some users even anticipate the dialog and use this as a shortcut to saving when exiting. Now along comes an app that asks the question "File has been modified, to you wish to exit?" providing "Yes" and "No" buttons. The user, conditioned to the behavior of most Windows apps clicks "Yes", losing their changes. Stupid user... ;)
Master of the Obvious
Tuesday, October 11, 2005
 
 
Why do you expect people with very limited computer experience know how standard web forms work? Okay, that didn't help at all. In effort to be more constructive, here are some reasons why their behavior may be perfectly reasonable:

1. What is being asked and how? Maybe they don't see the need to give all the data. Maybe they aren't always sure what they should enter. The layout can also contribute to missed fields, and the form might require the data in an unfamiliar format. Preventing errors is better than handling them.

2. What is the context? Maybe these people have more pressing matters in mind when they use the application. For example, a call center worker might have the next call forwarded to him while he still is filing last bits of information about the previous call. Correct the context or take the context in account.

3. What would happen if the data was correct? Success and failure should be clearly differentiated. This differentiation should go beyond simply adding a message. The resulting page as a whole should look different depending on the outcome. There should clear signs of closure on success and non-closure on failure.

4. Would there be a way to handle incomplete data? Maybe it could be saved until the next session. Maybe people should be given an option to submit the "erroneous" data, and get a callback if some other person can't fill in the details. After all, both things are possible with paper forms.

5. Is the environment consistent? What do the other applications the people use do when they can't process a form? Do similar problems occur with those applications?

And finally, maybe training isn't that terrible option. If the application is a conventional web application, maybe the people having problems really do need some more information about how things tend to work on the web.

In any case, the story might not be over yet.
Aapo Laitinen Send private email
Tuesday, October 11, 2005
 
 
Another thing to remember about making error messages and other things "obvious" is the concept of visual contrast. Recognize that there's a scale of emphasis on the page, and it's largely a zero-sum game.  You can make one thing very obvious, or several things somewhat obvious. 

The OP went from red/bold text to larger/red/bold/on a yellow bg/with a red border text.  Maybe the problem was that all the error text was red and bold in the first place. 

Since users never read anyway, making the text itself attention-getting is often futile.  I find you have to first get their attention, then hope that they read.  For example, use a huge yellow triangle with an exclamation point next to the error message in normal text.  Make sure the error message is short and descriptive (copy writing is hard!). 

It's a tough problem, but "screaming louder" isn't the only option.
EAW Send private email
Tuesday, October 11, 2005
 
 
One of the tenets of UI design that I've tried to adhere to (and I don't remember who said it) is "If it doesn't work the way the customer expects, it's broken".

Of course, there's no accounting for stupidity!
Steve Moyer Send private email
Tuesday, October 11, 2005
 
 
I should point out that this "not reading the error" was not a typical response. There were a large bunch of people using the system and only a couple of them had this problem. Upon examination of the problem it was decided that it wasn't obvious enough that there had been an error because we weren't obstructing their process in a significant enough way to force them to realise that they've created a problem.

Incidentally, the system is a performance management reporting system for the state fire and rescue service where I live. The screen in question is for the stations to enter in the monthly targets for the current financial year for each different type of task that they have to perform. Each set of targets that they enter must add up to some pre-existing annual figure, although it's up to them to decide how they're dividing that annual target up between the months. The problem was that they'd enter in figures, they wouldn't add up to the annual target, and then they'd ignore the fact that they didn't add up. Due to the existing database structure, I'm not allowed to save the targets they enter if they don't add up. Hence the user entered in all their targets, pressed "Save", ignored the error messages and closed the page.
Nathan Ridley [View My Blog!] Send private email
Tuesday, October 11, 2005
 
 
So occasionally the user enters a bunch of fields then hits Save, but doesn’t stick around to see if the next page says it was actually saved or not. I’m not surprised. As far as the user is concerned, the task ends when they hit Save. That bright flashy page that follows? Aw, the web is always throwing colorful stuff at you that’s irrelevant.

And that’s the problem. Computers in general, and the web in particular throw so much at users that is irrelevant to their task, that non-power-user can do nothing but put on blinders and focus on the few things they actually recognize. Indeed, with all our best attention-getting techniques being usurped by advertisers, I wonder if users are learning that the *more* in-your-face something is, the *less* likely it actually matters to your task. The same spills over to message boxes: how many actually provide helpful information? How many are even understandable if they *do* provide helpful information? How often can a user get away with just clicking cancel? Would you like to update Windows Media Player now? How about RealPlayer? Javascript error: Would you like to debug? This web page includes both secure and nonsecure controls –continue? Cannot show this page without resending data –okay? The certificate for this site has expired -continue? Windows login? Just hit cancel. This program has performed and illegal operation.

Not to mention pop-ups –and don’t expect users to distinguish legitimate message boxes from pop-ups. Frankly, I don’t blame users for developing a kill-that-annoying-box reflex.

But back to your problem. Telling users their input is invalid after the fact kind of sucks in any case, as you’ve pointed out. So how about if you just dynamically change the annual target to match the sum of whatever individual inputs the user makes, and thus making the error impossible? Or choose one individual target that’ll make sense to users that is *fixed* to be the difference between the total and the sum of all other individual targets?  No can do? Well, what if you display a thermometer in a place that doesn’t scroll out of view, where the annual target is marked (and can be edited). As the user enters individual targets, the “mercury” rises up to the annual target. Maybe you can provide some redundant brief text hints too (e.g. “Total 134 hours *too high*”) If the mercury is at the target, the Save button next to the thermometer becomes enabled. Note that these solutions not only make the error impossible before saving, they also help the user manage the task. Is it really user friendly to expect users to work out the targets on paper with a hand calculator then punch them in?

Yeah, such an interface is a real pain to do in your basic web form. That’s the other thing. Your basic HTML sucks for interaction.
Michael Zuschlag
Tuesday, October 11, 2005
 
 
Users don't read anything on the screen because they're tired of spending 10 minutes to fill out a form, only to get an error like "INVALID FIELD: password must be 8 characters and the 4th character must be -,+,@,# or $" so they click "Back" and the form is empty and they have to fill it all out again. This is why they lump web programmers with telemarketers, and have zero patience. You need to idiot-proof everything, and assume they'll screw anything up that can be.
John
Wednesday, October 12, 2005
 
 
What if you used Javascript to make sure the fields added up before the form was submitted. I know its a little unelegant and non-foolproof, but you could keep your current scheme in place as well (in case they have Javascript turned off etc)
Daniel S
Wednesday, October 12, 2005
 
 
Here's a fourth alternative to the others I gave above. Have a vertical bar representing the annual total with multiple sliders along it for the user to set the amounts of each individual target -sort of like an interactive stacked bar graph. Include redundant editable text boxes next to each slider with raw values or percents or both. Yow. Now I'm talking about inventing your own controls. But again, you can make the error impossible.

I guess the real question is, how do your users approach the problem? Do they have a precise idea on the value of each target and just want the annual total to be reasonable? Or, do they get the annual total as a "hard" value from somewhere, and divide it up among the individual targets using a rule of thumb for the proportions? Or what?
Michael Zuschlag
Wednesday, October 12, 2005
 
 
Along these lines, I got an email from a user of my freeware product yesterday, complaining that they uninstalled it "without even using it".  Why?  "[B]ecause it has not one but three nag-screens.  No good.  Not for a freebie and especially not for trialware."

Ignoring the fact that the product isn't "trialware" (it's free), the user has confused "nag screens" with "message boxes"!  "Nag screens" are those annoying "buy today, don't delay" dialogs.  What my freeware program pops are simple message boxes, which contain important and useful information for first- time users.  How a user could be so benighted as to not understand that I'm not trying to extort money from them, I'm trying to *help* them, and for FREE, is beyond me.

The punch-line is that these are not standard message boxes, they are my custom ones, which include a little "Don't show me this every time" checkbox.  I don't know how to make it any less obtrusive.

The moral of the story is, not only do users not read what's in front of them, half the time they don't even understand what the program is doing.

Wednesday, October 12, 2005
 
 
How the original poster has the audacity to return to an EMPTY form, is beyond me.
some guy
Wednesday, October 12, 2005
 
 
That sounds like something I would do.  Remove the program before I get into it.  If you have to nag me that much during startup, then something isn't right.

I recently returned a pack of software because they didn't pay attention to my user settings and included sound effects on all actions (clicks, window changes, min/max, etc). 

They claim they have fixed it, so I might try it out again.  But I doubt it... I can find someone else who has a similar product that doesn't annoy me.  Even if it is slightly inferior.
Eric D. Burdo Send private email
Wednesday, October 12, 2005
 
 
Some types of applications have a lot of competition with similar offerings, and the difference then is in the subtle features. One may be easier to use or just "feel right" while something else may be more powerful but feels clunky and inconvenient.
Briguy
Wednesday, October 12, 2005
 
 
Hmmm.

I've sent out emails to internal customers like the following:

===========================================================
"To: AllFernandasCustomers

"Re: SPLODGE application has been moved

"All,

"The SPLODGE application has been moved and is now located at '\\FOO\Bar\Baz\Quux\SPLODGE.spl'.

"This is a change from the previous location of '\\PIPPO\Pluto\Paperino\SPLODGE.spl'.

"Regards, etc"

===========================================================

Weeks or months later, I've had angry emails from those customers:

===========================================================
"To: Fernanda Stickpot, FernandasBoss, FernandasOtherBoss, BigManager, AllFernandasCustomers

"Re: SPLODGE application has been moved

"Frenanda,

"The SPLIDGE program doesnt work!!! we have lost a days work over tihs!!! Has somebody moved it?!?

"FernandasBoss, BigManager, FernandasOtherBoss, please escalate this, it is now URGENT!!!

"Regards, etc"

===========================================================
>"To: AllFernandasCustomers

> "Re: SPLODGE application has been moved

>"All,

>"The SPLODGE application has been moved and is now    >located at '\\FOO\Bar\Baz\Quux\SPLODGE.spl'.

>"This is a change from the previous location >of '\\PIPPO\Pluto\Paperino\SPLODGE.spl'.

>"Regards, etc"

===========================================================

===========================================================

I ask them, "And what happens when you copy and paste '\\FOO\Bar\Baz\Quux\SPLODGE.spl' into your Explorer address bar and press Enter? Could you send me a copy of the error message you get when you try that?"

I never hear from them again.

This is a near-verbatim transcription of actual correspondence, by the way - it is not exaggeration. And similar things have happened more than once.

The part that surprises me isn't the part where they didn't notice the message that SPLODGE had been moved. It was the equivalent of spam to them, at the time they received it.

No, the part that surprises me is that their frantic pleas for intervention are sent to me AS A REPLY TO THE MESSAGE THAT SPLODGE HAS BEEN MOVED!

The question is: if I had phoned each of them individually to tell them, would that have made any difference? Would it have worked to visit each of them in person?
Fernanda Stickpot
Friday, October 14, 2005
 
 
DOesn't neccessarily help.

I've spoken to people face-to-face saying that "files here get backed up - files over there do not get backed up."

Yet they, from time to time, re-arrange the files all over the place, wreaking havoc with the backup program, which now sees 99% of files being changed, and might not back up any more.

(Granted, some technical things can change, given this hindsight - but shows that face-to-face communication doesn't neccessarily help)
Arafangion Send private email
Friday, October 14, 2005
 
 
Hmmm. I asked this because of the oft-repeated conventional wisdom that e-mail is the worst possible way of conveying information.

It's one thing for us, since we use newsgroups and bulletin boards all the time. But according to myth and legend, non-nerds don't get any useful information via the written word.

This does seem to have some basis in reality; many people just don't seem able or willing to understand anything unless you go and talk to them about it. Even among technerds, my requests for documentation are usually met with "I don't have any documentation, I'll just come and tell you about it." Then I'm expected to sit there and take in their wordy explanations right there on the spot, and if I don't remember it all, or identify all the discrepancies before they leave, that's it. I don't see how this is any better than being left to work it out for myself, except that it wastes more time, but maybe that's just me.

I'm prepared to believe that I'm genuinely unusual in finding the written word an ideal way to convey specific information. I don't learn from lectures very well, so if I don't have a book from which I can absorb all the material before I go, I won't learn anything. Conversely, others don't seem to feel that they've learned anything until they've been to a lecture and had someone tell them about the material, *even if* it was all in the pre-study books.

On a customer level, going to see them is really what makes them trust you, even if it's just to say what you already said.

I have to wonder to what extent most adults are *genuinely* unable to make use of written information, and to what extent we, as developers, can consider it our responsibility to address that.

Seriously - if applications spoke the error messages, would they make more sense to the user?

Maybe if I just put the same message everywhere: "Something happened. Phone Fernanda," for EVERY event, not just errors. They wouldn't read the message, but it would only be telling them to do what they're going to do anyway, and I could go over and tell them face to face what just happened. "You need to log in." Saves them a few milliseconds emailing me to ask me what their login is. :-P
Fernanda Stickpot
Friday, October 14, 2005
 
 
Why don't you save the information and let the user correct it later?

Or use javascript to valid the form.

To be honest when I click the "Save" button I expect it to go to the next screen. It throws me for half a second when I see the same screen again.

Whereas if I see a javascript popup I think "ok I am still on the same page but I need to do something".

Ultimately, if more than one user does this, it is not your fault but it is your problem.

-Andrew
Teambob Send private email
Saturday, October 22, 2005
 
 
One more possibility for original problem.  If the user can receive useful information from a confirmation screen ... (don't know enough about the context of the application to know what this info would be or if there is any) then they are more likely to look for it.  When they don't receive it (because of the validation error) they would hopefully be less likely to simply exit the form.

Of course, a colletion of users will tell you your application is now broke because it is behaving differently than before. 

And jeevus help you if a page needs to be added between the initial one and the confirmation....
Eli Burpee Send private email
Tuesday, November 01, 2005
 
 
My little idea to prevent the problem:

1. Change the [save] button to [preview]
2. if data is valid:
    show them a page with a button [save]
  else:
    show them a page similiar to the first
    (with error message and [preview] button, no [save])
billyswong
Thursday, November 03, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz