Messaging when user does not have permission to edit some data

25 Jun 2009 - 8:35pm
7 years ago
3 replies
941 reads
R Sengers

I'm working on an app where users have fine-grained permissions to edit
specific bits of data on a page (edit buttons appear next to each set of
data). The problem is, when users don't have the permission to edit the
data, then they think it's not editable - period. They don't realize someone
else in their organization might have permission to change it. Instead, they
call the app host's customer service.

What's a friendly, non-obtrusive way to let them know that even though they
cannot edit the data, someone else might be able to?

There are some sensitivities around this. Organization might not want one
person to know that another person(s) in their office has more permissions
than they do. So we might not want to list their names.

- Show the edit button next to the data, but gray it out. When user clicks
it, a tooltip appears w/ a generic message: they should ask an administrator
if changes need to be made to that data.
- Within an edit form, if there are extra options that this user doesn't
get, display a generic message: they should ask an administrator if other
changes need to be made to that data.
- If the company is willing to have a point person, show that person's name
in the message.

Do you have other ideas?



25 Jun 2009 - 9:40pm
Stephen Holmes

How about a suggestions box.

have a simple pale non-obtrusive graphic they can click on and then a
text box allows them to suggest changes. It then goes off to a person
who has the required permissions - or off to a committee (TFIC - I
work in government :-) - and the change option is at least captured
on the fly.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new

26 Jun 2009 - 4:16pm
Ivan Burmistrov

I think the solution with graying out Edit buttons is good because:

(1) graying out is a well-known standard,

(2) it does not hide full form functionality,

(3) it doesn not require form redraw when buttons become active,

(4) it motivates the user to find the way to make disabled buttons

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new

29 Jun 2009 - 9:36am

When faced with something like this I usually start asking questions.
(And the answers usually point to the need for some process change
rather than new design ideas).

If user X does not have permission to edit the data, what is the
benefit/need for them to know that someone else can edit it? i.e. Why
indicate that it's editable for user X when it's not (for user X).

Since the app already knows user permissions, craft the pages so that
the permissions determine the presence (or absence) of the Edit Button
next to the field.

Users with permissions see the button, users without permission
don't see the button.

If there really is a need for user X to know that someone else can
change the data (and user X has some dependency on others for making
those changes)...and...if sensitivities are an issue...identify the
users who have permissions anonymously and have the messaging contain
a link to alert the permissioned folks. (ie: "Send change request to
[this data field's] administrators")

FYI - The grayed out concept may not be understood 100%. I worked on
an app where the grayed out concept was used (not for permissions, but
for indicating that a form was not complete/ready to be submitted) and
tons of users thought it was just "broken" (due to low confidence in
the app because of a myriad of other usability issues) and they
constantly called the support folks to have it "fixed".

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new

Syndicate content Get the feed