Should we try and avoid fail states at all cost or allow users to recover from fail states?

Question

Today, I came across a site where the submit button to a login form was disabled unless you have filled in the username and password. Unfortunately, I could not reall the URL, but it looked like this:

^{download bmml source – Wireframes created with Balsamiq Mockups}

I have also seen this pattern (or perhaps anti-pattern) being used in software installation screens:

^{download bmml source}

From these 2 examples, the possibility of a fail state is either reduced or completely removed:

• In the login form, the failure state where either both or one of the fields is blank will never occur.

• In the license agreement example, there will never be a fail state.

I feel that these type of interfaces lack feedback to the user. I would prefer to let the user fail and then display a mesage to assist them to recover.

For example, in the license agreement example, if the user is not familiar with disabled buttons, he could keep clicking the button, but still find that the application is not doing anything.

Is there any rationale or reason for preventing failure states like this?

Answer 1

The addition to these of a roll-over that indicates why the button is disabled would improve these, but they are common and perfectly OK, and better than allowing failure when failure just looks stupid.

Recently, I submitted a complaint to the BBC. In the process there was a drop-down response to "Have you read the details of what comes next", with Yes and No options. However, if you select the "No" option, all it does its tell you you have to select Yes. This irritated me intensely, as the above pattern would have been a better way of indicating this.

Failure has two big problems. First, it can be expensive in terms of time and resources ( depending on how it is handled ), and secondly, it interrupts the users flow of process. Disabling buttons is a good way of indicating "You are not yet ready to click this", and fits with the idea of only letting people do things that make sense.

I would prefer to let the user fail and then display a message to assist them to recover.

I think this is the core problem here. Letting the user fail is usually wrong - it often ends up (as it would in these scenarios) as very patronising. Guiding the user to success is a far better approach, and normally ends up being supportative. If the computer knows that I shouldn't be able to click "log in" yet, why does it let me? The answer is usually "You hate me", in some form, which does not give a good impression.

Answer 2

I would prefer to let the user fail and then display a mesage to assist them to recover.

What purpose does failure serve?

The only reason you would want to deliberately allow someone to fail is so they can avoid it in the future. But if you can remove failure entirely, why is the learning process necessary?

I don't believe that making users feel like they are stupid (and failure always does this, unless the user can blame the system - an equally undesirable outcome) is ever a desirable thing in UX design. Failure and recovery are unnecessary steps towards a user completing their goal, so why have them at all?

The rationale for preventing failure states is that they are irrelevant to the user, hinder their progress, and degrade their experience by either insulting them, making them feel inadequate or making them feel like they're fighting against the interface.

The question only remains as to whether it is possible to avoid all failure states. Maybe this is not the case for certain applications given other constraints - and in that case, perhaps learning to avoid failure by failing might be useful. However I don't believe that we need to accept failure as a part of every process.

To deal with your example specifically - the reason that it is a bad example is that it substitutes one failure state for another. If you were worried that users would fail by clicking on an inactive button, remove the button and find a different control that works. Hell, don't have an "I agree" checkbox at all - just have a button which does performs the whole action.

Answer 3

Since there are several "layers" of error-prevention and feedback-loop, there isn't any single answer to your question.

You need to consider each issue individually and choose the appropriate error prevention / feedback model. (Yeah. And you should also consider each issue to each other.)

Error prevention:
- Hide option
- Disable option
- Enable option (and raise an error)
- Enable option (and ignore consequences)

Sometimes it is appropriate to actually hide input fields, menu items and buttons, but in other situations it is better to show the UI elements, but to disable them. If they are visible and disabled, it must be clear why it is disabled. If that's not clear, then it might be better to enable the UI element and give a proper feedback if the users uses this.

The "Print" action is an example of an action that could be enabled, and give error message if there is no printer available.

The "Cut" and "Copy" actions should not be enabled all the time, only when you have chosen something you actually can cut/copy.

"Table tools" and "Image correction tools" etc should only be visible when you are actually working with such an element.

Feedback:
- Passive feedback (hint/instruction)
- Immediate feedback (timely hints related to what you're doing)
- Interruptive feedback (dialog that interrupts your work-flow)
- Batch feedback (Submit info and get feedback on everything)

Sometimes it is enough to just give some discrete hints or instructions. "Fill out every field marked with *)" or "No decimals needed". But in other situations, it might be nice to give a clearer message to the user, but avoid to interrupt the work-flow. Eg. invalid e-mail or invalid social security number. The important issue here is whether the information is helpful to the user at that moment, and not a disturbing element. You can validate on field exit or while the user is editing. It depends. Event the latter one can be aggressive or subtle. If you enter an e-mail, there is no need to yell out "invalid e-mail" right after the first character is entered, because the user will probably fill in the rest of the e-mail address. You could wait until you know that the e-mail really will be invalid. Eg the moment he enters two @'s or an invalid char.

For some situations (especially intersection validation), it might be better to let the user complete the form and submit the form and then provide a proper list of errors.