I work as a graphic/UX designer for a company that produces an highly complex web SAS. Lately, I've been confronted to a complex issue related to one of our app's functionalists.

Our apps generates a list of entries where for each entry, functionality can be activated most of the time. For permission reasons, some of these entries can't have that functionality activated.

I've been arguing with the developers because they are planning to leave the button that activates the functionality even for the entries that doesn't allow it because it would be highly complicated to isolate the entries concerned by this exception. In a nutshell, that would mean that for some of the entries, the users would be able to see and click on the button, but it wouldn't result in any feedback/action at all.

Are there any articles that clearly state that leaving a dull/dead/inactive UI element misleads the users by giving them the false impression and that their action will lead to a result is a major usability failure? I found articles about greyed UI elements and errors of several kinds, but I haven't been able to find something that precisely stipulates that.

  • Isn't common sense enough to realize that showing a button that does nothing is confusing? Your developers sound lazy.
    – Kip
    Dec 2, 2015 at 22:22

2 Answers 2


The usability heuristics from NNG address this. http://www.nngroup.com/articles/ten-usability-heuristics/

Consistency and standards - Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.

Or if the same button may or may not work.

Error prevention - Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.

Such as disabling the button when an item cannot have an action. Or making clear that certain items are not available.

Recognition rather than recall - Minimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.

The user should not have to have memorized which items should* work when the button is pressed.

Help users recognize, diagnose, and recover from errors - Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.

Users should be able to get feedback on their action to know if it is successful or not. If there is no feedback they cannot troubleshoot if there is a problem.

  • Outside of UX, the developers may be worried about how long this modification would take them. This could be because the system wasn't designed to handle events like this and they are trying to get other features out the door. If you have a stakeholder, boss, scrum master, or product owner that can referee get them involved and make your case for why this "seemingly" insignificant change is so important. If you can get buy in to move the developer's other work around so the developer has space to work you may not have to argue with them at all. (Good luck)
    – Chromarush
    Nov 2, 2015 at 19:02

Showing a button that pretends to work but does nothing at all, will certainly make the tool appear broken (one could argue that it is broken at that point).

However, hiding the control can also be a bad idea.

It breaks expectations in that it leaves the user searching for something they believe should be "where it usually is" and misses the opportunity of communicating why the expected action is not available.

Users are best informed about the inactive state by visual cues and some help text in the appropriate form (tooltip / label / icon).

This short blogpost, back from 2008, sums it up nicely:

When a function is unavailable due to current system state, but may be enabled for the current user when the state changes, the control should be disabled. This provides a visual indication that the function exists, and the user knows that there is an action they can take to enable it. When possible, I specify a tooltip that explains why the function is disabled. If a function will never be made available to the current user (barring a change of the user’s access privileges), it should never be seen by the user.

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.