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.)

  • 1
    Sometimes obvious truths are valid. I know management doesn't always agree, but...
    – DA01
    Sep 24, 2012 at 16:07
  • 1
    @DA01 You should see the email I'm staring at. They point out explicitly that the user will have no idea why the option is disabled... as a GOOD thing! Sep 24, 2012 at 16:08
  • 1
    Actually, the core of this question is a great one: How can UX teams best use their gained knowledge, skills, and common sense to make a case to management when management has no interest in respecting anything UX states unless verified by a 3rd party? (Which is, sadly, not uncommon)
    – DA01
    Sep 24, 2012 at 16:09
  • 5
    Tell them they absolutely can't do it. When they ask you why, don't say anything. Then say "Well, how did that feel"? Sep 24, 2012 at 18:32
  • 1
    You wouldn't believe the shouting-down I got last week when I pointed out this very idea. It's evidently very controversial. I still think disabling without explanation is bad, though. Sep 24, 2012 at 22:53

2 Answers 2


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.

  • Can you add further details as to why this supports or counters the OP's position? Sep 24, 2012 at 22:52
  • @JimmyBreck-McKye: Sorry, yes, expanded and added some refs.
    – Aesin
    Sep 24, 2012 at 23:16

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)

  • Useful, but not quite appropriate here. The user CAN do something to enable the control, but my concern is that they won't be able to figure it out, and even when they do, it'll be seen as a bug due to the sheer weirdness of the steps taken. Sep 24, 2012 at 16:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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