As a web developer I have often found myself explaining to clients and users that it is not their fault when something is broken. Aside from the obvious fatal code errors and suchlike, I have had to deal with users, often during testing, who have said they are sorry they must have done something wrong and it didn't work, or some other specific variation of this apportioning of blame to themselves.

This has made me come up with the adage, which I repeat in such circumstances, that the user is never in the wrong, it is always the fault of the interface designers if their users are making mistakes when using a tool.

Is such a sentiment covered by the leading global experts in the field of user experience and what are some choice conclusions reached?

  • First: user should never see an error message. That makes them fear. If something doesn't work without explanation, is them a simple situation: they ask you to fix. The place of the error codes is in your server logs.
    – user38535
    Nov 26 '13 at 22:06
  • more a question of principle than implementation, i.e. the answer could quite happily apply on top of a mountain, miles away from a machine one could code on
    – Toni Leigh
    Nov 26 '13 at 22:08
  • When I took an HCI course in university, I learned that when a user has difficulty using a product, the design can be improved (essentially, the designer is at fault). Not sure if this is something that I learned from the instructor or from the DOET; either way, it's completely changed my perspective of the world.
    – Dennis
    May 5 '14 at 18:15

Although I do the same, extolling that "there is no such thing as human error", that is simply not true. How "error" is defined and how it is put into context of the overall system is very important though. When most people hear "human error" they do not see the details, the see the person who is completely to blame.

Donald Norman's The Design of Everyday Things has a complete chapter on defining "human error".

There is also a very good breakdown at Measuring Usability. In the article "Measuring Error in the User Experience" talks about the two types of human error: (1) slips, and (2) mistakes.

In the article above 4 broad causes of error are defined:

  1. Slips: You can't eliminate all those "fat finger" errors or typos but seeing a lot of slips can be a good indication to reduce required fields or data entry where possible.
  2. Mistakes : When we see users entering the wrong format in a field it's usually a good indication that some field-hint, an auto format or some code that gracefully strips non-numeric characters might reduce these mistakes.
  3. User Interface Problems: Errors caused by the interface are the ones we're most interested in as we can usually do something about these. If users continue to click on a heading that's not clickable (mistake) or look for a product in the wrong part of the navigation then there's probably something about the design that we can improve.
  4. Scenario Errors: No matter how sophisticated and realistic our usability tests are, there is some degree of artificiality to them. For example, if you want to test how well users can pay a credit card bill online then you have to provide them with fake data and a test system. Inevitably we see errors related to the artificial scenario as users see balances and transactions that are foreign to them. We can't do much about these errors except note that they are unlikely to be encountered in actual use.

Given these categories the "fault" of an error can be put to both parties (the user, or the designer) depending on the situation.

In addition to "fat finger" errors, Robert J. Sternberg (1996) has called out "slips" as:

slips are most likely to occur (a) when we must deviate from a routine, and automatic processes inappropriately override intentional, controlled processes; or (b) when automatic processes are interrupted - usually as a result of external events or data, but sometimes as a result of internal events, such as highly distracting thoughts.

Source: Human error (slips and mistakes)

Mistakes are something we do have power over, though can not stop entirely. Typing a search string into the wrong box, thus choosing a wrong method to achieve your goal, could be an example of a mistake.

Given time, a mistake can turn into a problem with the user interface (#3). If users are consistently making a mistake as to where to type that search query, that can indicate the error lays more with the user interface. That is not to say, however, that all mistakes are user interface issues in sheep's clothing... people just make mistakes somethings.

As UX professionals it is our job to argue for and represent the interest of the users. Part of that effort sometimes includes not pointing out their faults to them or non-UX people (e.g., management). We are here to eliminate problems with the user interface and reduce our own weaknesses in scenario design, as well as mitigate slips and mistakes.


I think that it's not necessarily very constructive to frame things in the context of "whose fault it is". No product team will ever get a product 100% perfect on the first try, that's why you test and iterate.

Also, although the experience of the user is often of critical importance, if you left some things up to the user the company probably would go bankrupt, therefore you have to balance the needs of both the users and the company's bottom line. Again though, I wouldn't put it in the context of whose fault it is.


Your view that the user is never wrong is to some extent not only a shared sentiment but a fundamental UX concept. Here is some food for thoughts.

There is no such thing as stupid users - only expert supremacy

People often feel 'stupid' due to lack of experience or expertise. This is normal behaviour - if you travel to Enfield and buy an overpriced match tickets from a tout, only to find out at the gates that they are fake, you, your friends and locals (who may have done the same in the past) may consider the act 'stupid'. But it's rather a case of inexperience, not stupidity. If you repeat the same mistake twice, you are a slow-learner, but not stupid.

It's not the designer's fault

User testing is integral in UX to confirm assumptions made by the designer and to explore unforeseen issues. If only designers could test a system before it was designed; but per Einstein, this would violate the cause-and-effect principle.

Users to designers are like toddlers to adults

We don't blame, or call stupid, a 2 year old toddler for trying to drink from a sealed bottle - we acknowledge they haven't mastered many skills yet. Adults, however, should know better.

Similarly, anyone involved with a system would know it much better than a test user, yet as the user is an adult we still expect them to know better, although they don't stand a chance to know as much as us.

We learn from mistakes not from successes

As a teacher, I sometimes give a practical task to my students. The worse learning scenario is that the students perform the task without encountering a single issue. In the real world issues are common, so the more you are aware of possible mistakes, the less likely you are to make them.

This is also a key principle in design - "Fail fast, succeed sooner".

The remote control example

The previous point is something that is important to explain to users in the pre-test introduction. If time allows, I sometimes bring a complicated remote control with me and tell the user:

Imagine I try to understand design issues with this remote control, so I give it to you for 3 days, ask you to use it at home, then come back and report any issues you had.

Now imagine that you don't want to come across as stupid, so despite a multitude of issues you experience, you spend hours on end trying to figure things out and after 18 you succeed. Then you come back to me and tell me 'I had no issues - it's really easy to use, I can show you any feature on it'.

How would that serve real prospect users? How would it help us improve the product?

It is important to stress to participants that while we are delighted by success, it is difficulties that help us improve.

The user is not always right; users are

With all this in mind, it is important to remember that some participants' behaviour is nothing but extreme exception to the norm. This is why testing is ideally done with a good amount of subjects.

A user view that half the display should be a massive back button is unlikely to repeat with other participants.

So while the user is never 'wrong', a user is not always 'right'.


A system designer is responsible for what a user does the same way that a boss is responsible for what his directs do.

Responsibilty is a matter of the role.

That said it's perfectly fine if a system tells a user that something he did was wrong and that the user should interact with the system differently.


To generalize and say "a user is never wrong" and "the designer is always at fault" is bad. Some users are wrong and some designs are not always at fault.... I would refrain the generalization. But yes, users can and should make mistakes when using an interface and it's really only the fault of the designer when they fail to take any action to smooth out the bumps. Not all interfaces are perfect and neither are users, so mistakes will always be made.


No it is not always the fault of the designer, but it can be sloppy design to allow users to be at fault.

From a designers point of view, the real question is often about cause and what can be done about it, not fault.

Fault is most useful if you need to find someone (or something) culpable. Designers are more interested in why something went (or could go) wrong and to design against it. Stopping at, or even concentrating on fault is usually not very helpful from a design point of view.

Cause can be much more complicated (and in my opinion fascinating) than fault, there are usually many elements at play. While you are constantly asking questions about cause, you can start exploring solutions, mitigations, changes in use, and all sorts of other design type activities.

For instance you may have a section of road were lots of hedgehogs get killed. This is a problem. Who is at fault? The fault could lie with the drivers (not avoiding them), the designer of the cars (making them too solid), the hedgehogs themselves (not avoiding cars, not using a zebra crossing, being too soft and squishy), the road designer, etc.

If you analyse the cause you could try asking many why questions.

Why are the animals being killed? Because the cars keep hitting them.

Can I do anything about this? Can't think of anything sensible - ask more questions.

Why do the cars hit them? Because the hedgehogs are crossing the road.

Why are they crossing the road? I'm not sure lets find out.

Could it be because their normal route is blocked for some reason - if so clearing the blockage could sort the problem.

Could it be because the road was build on top of their normal route - if so can anything be done about this - a hedgehog underpass maybe?

A simplified example - but you get the gist.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.