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”?
Related:
Methodologies for Managing Users and Access?
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.
3