Our software implements a layer of role-based security to secure data access, in the form of access control lists. Whenever a user tries to do something that isn't allowed, the software layer will receive an "access denied" error code or exception.

Having seen how our customers react to such "access denied" messages, and their negative impression to our software as a result, I've been thinking about how we should modify that message to make it less stressful.

I understand that the best way to reduce such frustration is to simply hide the UI actions that a user is not authorized to do. However, our UI is very feature-rich and it is not always possible to predict whether a UI action will result in access-denied error.

From a user's point of view, it would be nice if the user can be told "what went wrong", i.e. explained in the same way that a human IT administrator would explain.

My question

  • From a user-friendliness standpoint, what is the best way to present an "access denied" message without offending or frightening the user?
  • From a software design standpoint, what design methodologies can be used to reduce the chance of a user seeing an access-denied situation?

Some thoughts

  • If there is a security rule that says someone is forbidden from viewing a piece of data, then:

    • If the user has low trust (e.g. general public), no explanation for the "access denied" should be given because any partial information could be used against the security.
    • If the user has partial trust (e.g. an employee in the customer's organization whose rank is not high enough, or works in a different department), perhaps some explanation can be given to the user so that the user knows what security rule is being enforced?
  • However, occasionally some security setup is based on "denied by default", meaning that in the absence of a rule granting access, nobody can access anything.

    • In this case, it is much harder for a software system to explain to the user why the "access denied" occurred. Maybe it is a configuration error (a human error)? Maybe a security rule is indeed being enforced in the way of the lack of a "access granting rule"?


Methodologies for Managing Users and Access?


1 Answer 1


The best solution in this case (and it is mentioned in the question) is simply to remove, or even better, to disable the UI elements that lead to "Access denied" actions. This way, the user will know that they can't do this action. Additionally, some hints can be displayed on these elements that to explain: "Disabled, because this action requires more privileges." or something similar.

The statement

"our UI is very feature-rich"

is a stupid excuse not to use this method. Any other solution will cause annoyance to the user, regardless of how politely you phrase the reason in the error message.

Well, OK, I will write about another acceptable method:
Instead of error message, the program must give the user chance to raise their privileges on such actions. Some dialog box that says: "You need additional privileges in order to perform this action. Please, provide your username/password." and corresponding user/password edits (or whatever controls you are using for authentication).
Also, OK/Cancel buttons. If the user presses "Cancel" no additional action is provided. If the user presses OK without acceptable user/password - provide error message "Access denied for specified user" or "Wrong password" or other consistent message and go back to the dialog for second try.

This way, the user will cancel the action himself, so the user will be less annoyed.

  • @SteB - thanks for the editing. My English is really awful. :)
    – johnfound
    Feb 3, 2013 at 16:11
  • 1
    +1 a "feature-rich UI" probably should construct its menus dynamically anyway, so applying security restrictions is a logical next step. It ain't easy, but I've seen it done, and it makes for a much better UI. Feb 3, 2013 at 16:58
  • "our UI is very feature-rich" - likewise I don't buy this as an excuse; not being able to selectively disable (or remove) UI components based on user access rights seems more likely to indicate that your UI is very over-engineered instead, with perhaps at least one too many layers of abstraction in it. Feb 3, 2013 at 19:34

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.