When the user of a system (interface, class, whatever) makes a mistake when using it, this is indicative of a design flaw in the system as much as a failure on the part of the user. If you designed or built the system, resist the temptation to explain their mistake to them. Instead think about ways in which you might change the design so the mistake is less likely to happen next time. As Donald Norman says in TheDesignOfEverydayThings: "The designer shouldn't think of a simple dichotomy between errors and correct behavior; rather the entire interaction should be treated as a cooperative endeavor between person and machine, one in which misconceptions can arise on either side" ---- Yes, yes, yes! I certainly HaveThisPattern. Apart from anything else, it's just so much ''politer''! Someone using your service, instead of rolling their own, is trying to DoTheRightThing. It's only fair to reciprocate. Sometimes, problems occur simply because the problem domain your service deals with is complicated, and they don't know it very well. Fine, you can sit down and teach them about the problem domain in that case. But if ''the same problem'' emerges more than once with ''different users'', that's a sure indicator that your interface is not all it should be. It's like correct usage in a language - there's a sense in which the "correct thing" is by definition what people do, not what the style guides say they should. I am always amazed when people start blaming others for incorrect usage of the services they provide. It just seems very (almost comically) shortsighted. Certainly doesn't make them look very sharp. Or, as I said, very polite. ---- On the gripping hand, it is possible that multiple people will simply make a mistake when using a product, due to lack of comprehension or training or simple common sense. "User error" can certainly ''indicate'' a design flaw, but does not conclusively prove that there is one. ---- But, if it's always the ''same'' mistake? Or the same mistake at least appears more than once? There's probably at least a confusing name involved there... I see people saying it's the user's fault when it comes to interface use far more than they accept responsibility. ''I agree. But I have also found that some users can't be bothered to learn how to use the tools that they have. Then they complain that it "doesn't work". '''If''' the user is following all the instructions they were given and there are still errors then either a) the instructions need to be updated or b) the system needs to be updated - either way it is rarely the user's "fault" when things don't go the right way. -- AnonymousDonor'' If multiple users can't be bothered to follow the instructions I'd think about making the instructions less bothersome to follow. --ChristianTaubman ''"Don't drink and drive." Such a simple instruction, yet different users around the world make the same mistake of not following it. Does that indicate a design flaw in cars?'' It probably indicates a design flaw in our transportation systems. : ''Or perhaps a design flaw in humans.'' : There bespeaks the precise blame-the-user mentality this page is meant to thwart. Drinking and driving is a clear cut example of the design flaw in drug policy (unsafe but legal alcohol versus safe but illegal marijuana) and transportation (see CarFree) or Yaerd for [http://www.yaerd.org/State-Drunk-Driving-Statistics.htm drinking and driving statistics] : I really liked this argument until I gained the understanding that "maijuana is safe" is much too general a precondition than I can accept. Could there be another answer one could give that would avoid this precondition? -- MartinHaecker ''How do you make this instruction less bothersome to follow?'' You enforce the law. That has its limits, so then you start to think about things you might be able to do so that people don't need to drive as much. Increasing the effectiveness of mass transit, for example. I have come across people who simply can't be bothered to learn how to use perfectly good tools. In that case, I (politely) point them at the documentation, and get back to work. I deal with them again once they've started doing a reasonable minimum of work. Helping out someone who can't be bothered to help themselves just makes things worse, since they get used to being bailed out. I suppose an analogue might be to ban people caught drink-driving automatically for some set period at least, and possibly to require proof that they had sought treatment for the alcohol problem they presumably have. And some countries do this. You can't stop people from being idiots, but you can act in ways that encourage them to get a clue or two. ''Most U.S. states have laws that force DUI'' ''"winners" to give up their driving privileges for a certain period and take courses. Is that what you mean?'' yep ---- Some mistakes can be detected and prevented, but others are very hard to detect and the correction may be worse than the problem. Real world example: for some forms, it was requested we block the entry of future dates, because these would not be valid on completed forms. It turns out, however, some users were pre-entering data the day before so that they could fill out the necessary information more quickly with the interviewee. After many complaints, this mistake-proofing check came out. ''Another way to fix this is to separate the data which can be pre-entered from that which '''needs''' to be entered in a time-sensitive environment. Can analysis of your forms help find this kind of fix?'' ''Consider adding a method to "complete" the form, and roll up all the error-checking at this point. That's when the date would be invalid. Using this method, the date could be filled automagically and would always indicate the form completion date.'' ---- See also PokaYoke