Summary: Communicating Permission levels...

11 Nov 2004 - 10:48am
9 years ago
2 replies
485 reads

(apologies again for cross-post)

Thanks to everyone who replied to my posting:
“Communicating Permission levels in the interface”.

Here’s the question I posted:

My team is working on a web-based application that will be used by several different people, in permission-based “roles”, to manage a financial services account. There will be the “owner” that can do everything, the “proxy” that can do nearly everything, and a “read-only” role. All of these roles will be allowed to “see” everything, and they will likely work closely together in a small-business setting (think: boss/assistant). We’re grappling with how to communicate these levels of permissions in the interface.

Opinion #1:
Design a single interface, for all three roles. Communicate permission levels by “graying out” functions that cannot be performed by a particular role.
This allows the user to know that the function would be there, but is not available to him/her because of the permission levels set. If permissions change for that user, the graying-out functions would appear where they’ve been all along, thereby limiting the learning curve as the user takes on a new role or plays multiple roles (their own personal account vs. company account). The development team would only have to build and maintain a single application, and the customer service reps would only have to be trained to support a single interface. The term “graying out” is being used to illustrate the concept, but this may very well be another visual treatment.

Opinion #2:
Graying-out links is confusing, because potentially large parts of the interface could potentially be seen but not accessible.
It would make more sense to assemble all the functions allowed for a particular role, and design an interface for each of these roles.

Summary of Responses:
The response was overwhelming – 35 notes in all. 7 of you voted for opinion #1, and 10 people voted for opinion #2. Most of the people who voted for opinion #2 found the other opinion “unacceptable”. However, typical of folks in our industry (and not surprising for the way I posted the question), the resounding response from the community was "it depends". I've boiled the replies down to these criteria:

Go with opinion #1 ONLY under the following conditions:
-If it is Important to see what the others can do (transparency between roles) – “oh, my boss can/should do that”
-If one role should know what the other roles can do
-If there is no emotional consequence – feeling resentful that you aren’t allowed
-If one person will be allowed to act on another’s behalf soon
-If there is an overlapping or sharing of roles
-If the roles are offering tech support to one another
-If roles are changing frequently
-If the function set is similar between the roles
-If the permission is account-level (can on some accounts, not on others)
-Important Note: If employing Opinion 1, be sure to employ a visual treatment to prevent visual clutter
-Use language to clearly indicate why some functions can and why others can’t be supported by a particular user
-Additional rule of thumb: If restricted functions are less than 50%

Thanks to everyone who contributed:
Patricia Oliver, Ted Booth, John Ferrara, David Heller, Crystal Kubitsky, Natalia Minibay, Dick Penn, Jef Raskin, Jim McCusker, Karen Whitly, Donna Cooper, Jon Ashley, Mark Singletary, Hilary Marsh, Jim Hoekema, Elizabeth Buie, Scott Nelson, Jeff Volzer, Cindy Lu, Pete Sullivan, Melissa L. Owsley, Paola Kathuria, Karl Swedberg, Henning Fritzenwalder, Susan Price, Rik Manhaeve, Maíra Carvalho, Sharyn Horowitz, Simon Grant, Tero Brooks, Patti Shank, David Unsworth, Quyen T, Jerry John, Chauncey Wilson

Andrew Conrad
Lead Information Designer


11 Nov 2004 - 10:55am
Greg Petroff

This is why this list is great. Thanks Conrad.


Gregory Petroff
desk 212 383 4092
mobile 646 387 2841

This message and its attachments may contain privileged and confidential
information. If you are not the intended recipient(s), you are prohibited
from printing, forwarding, saving or copying this email. If you have
received this e-mail in error, please immediately notify the sender and
delete this e-mail and its attachments from your computer.

12 Nov 2004 - 2:50am
Stephen Mallett

The application I am working uses Option 1 with the addition of a small "?"
button being presnt next to the greyed out button so that if motivated a
user can find out why they can't access a command.

-Ve a) takes more space to show "?" button
b) Someone needs to define the text to be displayed for the many
reasons a user can't access a command - part of my job

+Ve a) User can move from the intial - I am not allowed to. To find out why
and maybe questions why they are barred. Which will at least improve their
situantional awareness.


Syndicate content Get the feed