Reason why disabling options without explanation is bad?

Question

It seems to be an obvious truth: the user, when presented with the inability to perform an option with no clear reason why, will become frustrated. But are there any usability guidelines which outright state that options should not be disabled without explanation? Any usability studies I can point to?

(In this specific instance, due to the way a third-party control works, the developers have opted to disable the "cut" option when the entirety of a field is selected. This is a highly atypical setup and I'm concerned our users will find it confusing, but our SQA department doesn't have much weight unless we cite external research.)

Answer 1

A thing which makes a user stop and think "What? Why can't I do that? I can do that in any other thing." violates the Principle of Least Surprise, which, As I Understand It, is a fairly commonly held principle of (good) UI design.

From your question, it sounds like the Cut option is disabled only when the whole field is selected, which means that from a user's perspective, selecting one additional character can inexplicably disable functionality. With no explanation, and extrapolating from incomplete data, this could lead a user to conclude that "sometimes cut and pasting just breaks in this".

The general form of this principle is so general that it's hard to find specific recommendations to the contrary, but, this is from the OS X Human Interface guidelines, in the section on 'Consistency':

Is it consistent with people’s expectations? Is it consistent with people’s expectations? Does it meet the needs of the user without extraneous features? Does it conform to the user’s mental model?

Seemingly arbitrarily disabling functionality is not consistent with user expectations.

And, more specific to your needs:

When a user initiates an action, always provide an indication that your app has received the user’s input and is operating on it. Users want to know that a command is being carried out. If a command can’t be carried out, they want to know why it can’t and what can be done instead.

There's also a brief section in the GNOME3 Human Interface Guidlines entitled "Keep the User Informed", which includes the following:

The user should never have to guess about the status of the system or of your application.

Answer 2

Here is a blurb from Microsoft that I think does a good job at tackling this tough situation:

Reconsider disabled controls. Disabled controls can be hard to use because users literally have to deduce why they are disabled. Disable a control when users expect it to apply and they can easily deduce why the control is disabled. Remove the control when there is no way for users to enable it or they don't expect it to apply, or leave it enabled, but provide an error message when it is used incorrectly.

Tip: If you aren't sure whether you should disable a control or provide an error message, start by composing the error message that you might provide. If the error message contains helpful information that target users aren't likely to quickly deduce, leave the control enabled and provide the error. Otherwise, disable the control.

The short of it (and the way my team approaches this standard) is:

• Disable a control if the user can do something on that form to enable it (conditional, for example, in order to select a state from the dropdown, I might first have to enter the country)

• Remove a control if there is nothing the user can do to enable it (this might be a security related item, or dependent on a log in type)