Thanks to everyone who replied to my posting:
Communicating Permission levels in the interface.
Heres 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). Were grappling with how to communicate these levels of permissions in the interface.
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 theyve 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.
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 arent allowed
-If one person will be allowed to act on anothers 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 cant 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
Lead Information Designer
D I G I T A S