Communicating permission-based roles in the interface
17 Sep 2004 - 2:25pm
10 years ago
(sorry for cross-post)
Please take a moment to vote for one of two camps within my design team:
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.
The two camps:
Camp #1: Design a single interface, for all three roles, that communicates 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.
Camp #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.
Please send me your opinion camp 1, camp 2, or other (Im sure there will be many), and Ill summarize for the list. Also if you have any references that speak to this design, please pass them along!