Vtyjkyuk

From your description, I think the answer is pretty clear. I get your concerns about some users' expectations but this button shouldn't be shown for a few reasons.

A disabled button will only generate negative cognitive load for everybody.

Users will look at the button and think about what it does, how it's disabled, and how to enable it. You're saying the users can't enable it so it will be a question they can't answer or will be negative.

It's not a disabled button because it can't be enabled.

A disabled button indicates to users that there is an action they can take to enable it. By your description, this button can't be enabled. Don't show users a button that can't be used or enabled to be used.

It's a poor way to communicate

The things you want to try to communicate through this disabled button should just be communicated in plain text or through the UI. If there are different levels of control, show the users that and inform them which level they're on.

Is user likely to be aware of functionality?
Can an inexperienced user gain experience and then get the close privilege?

If yes, hide the button.

A button is extremely interactive element of a page. Consider these examples-

1. In Facebook, if you open a post in which you can only share, like and comments option are not displayed at all. Even though one can send a friend request and then like the post (once request is accepted).




2. In StackOverflow, if I do not have comment privilege yet, there is no comment option present.




3. A disabled button works well for empty inputs, i.e., until you have not written sufficient content, button is disabled. Or login button is disabled until captcha is filled. Or even for meetings, a button to join should be shown, but disabled until before 15 minutes. Here, user can come at designated time to join the meeting.

Simply put, showing a disabled button means there should be a way to enable it.
This is how me, or anyone expects them. A button disabled because of privileges should not be shown, because user cannot do anything to enable it.

In all the examples, user expects to get the button enabled after well defined specified time or action. In your case, user does not seem to have any well defined action to get the button enabled.

You can show text as 'You do not have close privilege yet.' It satisfies the curiosity of user, without motivating him to try for something he has no control over i.e. getting privilege.

One massive reason for disabling (with explanation) the button rather than hiding it which has not been mentioned explicitly is that an experienced user will at some point end up using an inexperienced user's account alongside them.

I commonly have a similar issue with a product we use internally that hides an admin button when being used by people with lower privileges. When training the new user or helping them complete their tasks I am sitting with them at their desk using their account and can't find the button to do what I need to. Having the button there but disabled would remind me that I'm using someone else's account who doesn't have access to the action that I want to complete so I need to log in as my own user to fix their issue.

You might say that this is a rather edge case but as people are being on-boarded and need training from and issues resolving by more experienced users the problems will escalate. It may seem like the experienced user should know that permissions are the problem but it is a very good idea to remind them!

The main driving force should be user expectation.

If the button is about a functionality that a user might expect to have, it should be there and the disabled state make it clear that it is not available (a hover tooltip can explain why).

If, however, it is a functionality that the user with the reduced access rights would not expect to have or see (or maybe even doesn't realize exists), it should be hidden.

In both cases, you are doing a trade-off.

Showing the disabled button makes it clear that the functionality exists, but is disabled, but could confuse the user who is wondering why you are showing him something that he can't do - and in the case of permissions, is unlikely to ever be able to do, unlike something that is only unavailable for temporary reasons, like, say, a "next" button that becomes enabled once the current wizard page has been filled out. One more advantage of hiding is that the layout of the page is the same for everyone, aiding muscle memory for people who might switch between different accounts or permissions, if there is such a thing in your application. It also allows documentation or help pages to refer to buttons by their position, as the position is invariant.

Hiding the button keeps the interface clean and useful, showing only what is actually available. It prevents "why they show this?" and "what would it do?" wondering by the user. However, if it is functionality a user might except, it replaces it with a different kind of "where is this?" wondering.

StackExchange shows buttons even when the user cannot take that action, and shows an advice if the user lacks the privilege to use it. In this case, the button is neither disabled nor hidden. There is, however, a motivation for SE users to gain reputation and enable buttons so it makes sense to dangle a "this is what you could win" prize in front of them and then tell them what they need to do to get it.. I guess you need to decide if such a behaviour suits you.

Also, perhaps this button can be purposed differently according to permissions, so that it's always usable. Restricted users can only [Close]. Advanced users can [Save and Close]..

Generally it's good to display a disabled button to let the user get used to the interface, know that he can perform that action, etc.

The exception to this would be if the user will never be able to use that button, if that's the case just hide it altogether.

It depends on what exactly you mean by "simply inquiring it." "Inquiring" could mean asking for a privilege to perform a given class of action unilaterally, or it could mean asking a senior user to perform a single action on the user's behalf. If requesting an action makes sense for your application, then a button to request an action could replace the button to perform it.

Stack Exchange has several request-and-review flows. These include flagging, voting to close questions, and voting to delete answers. For a quick concrete example, look at suggested edits. Only users with 2000 or more reputation can edit other users' questions or answers. But on main sites and Meta Stack Exchange (not child metas), users can propose revisions that get reviewed by other experienced users. The form for suggesting an edit resembles the ordinary edit form, with the following notice at the top:

Your edit will be placed in a queue until it is peer reviewed.

We welcome all constructive edits, but please make them substantial. Avoid trivial edits unless absolutely necessary.

Once a user has submitted a suggestion, the following notice appears near the suggestion:

Thanks for your edit!

This edit will be visible only to you until it is peer reviewed.

The post's owner can then accept or reject the edit, or other users with edit privilege can vote to accept or reject the edit.

My analogy is this:

Your users are in a closed room. Your users are thirsty but do not have the right to drink the water at the moment.

Do you think having a big picture of a sink will help the situation?

Obviously the answer is no. They will be frustrated that they can see what they need but they cannot interact with it.