Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

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

share|improve this question
1  
Sometimes obvious truths are valid. I know management doesn't always agree, but... –  DA01 Sep 24 '12 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! –  Yamikuronue Sep 24 '12 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 '12 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"? –  Vitaly Mijiritsky Sep 24 '12 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. –  Jimmy Breck-McKye Sep 24 '12 at 22:53
show 1 more comment

2 Answers

up vote 2 down vote accepted

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.

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

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)

share|improve this answer
    
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. –  Yamikuronue Sep 24 '12 at 16:49
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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