Communicating permission-based roles in the interface

17 Sep 2004 - 3:25pm
9 years ago
6 replies
714 reads
andrewconrad
2004

(sorry for cross-post)

Please take a moment to vote for one of two “camps” within my design team:

Background:

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.

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 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.

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 (I’m sure there will be many), and I’ll summarize for the list. Also – if you have any references that speak to this design, please pass them along!

Many Thanks,

Andrew Conrad
Lead Information Designer, DIGITAS
aconrad at digitas.com

Comments

17 Sep 2004 - 5:01pm
Jim McCusker
2004

conrad_ixdg at spamex.com wrote:

>Please send me your opinion – camp 1, camp 2, or other (I’m sure there will be many), and I’ll summarize for the list. Also – if you have any references that speak to this design, please pass them along!
>
>
My vote is for camp #1, assuming there is significant overlap between
the different roles. Are people "promoted" to higher roles, or will
there never be any crossover? If you organize things right, the user may
not notice that something is grayed out. Make sure that the more common
stuff is at the top of menus, or is more accessable (you don't want the
user to wade through lots of grayed-out options to get to the ones they
want). It's a bit more work to get right, but in camp 2, you'll have to
come up with an interface for each anyway.

A compromise between camp 1 and 2 is to build some sort of plugin
system, where you have the base UI, and then depending on the role of
the current user, the commands that they have access to show up.
Minimize menu change (or get rid of it and deal with grayed-out menus)
by finding common ground between the actions in the different roles.

Jim

17 Sep 2004 - 5:15pm
Ted Booth
2004

This seems like more of an organizational culture/adminstration
question. Either #1 or #2 would work from a strict UI point of view.
But from an organizational point of view, they have very different
impacts.

#1 allows everyone to everything, but limits their access to specific
things based on their position in the hierarchy
#2 shows users only 'what they need to know'

From an operational management point of view, #2 is probably the better
option.

On Sep 17, 2004, at 1:25 PM, conrad_ixdg at spamex.com wrote:
> Please take a moment to vote for one of two “camps” within my design
> team:
>
> Background:
>
> 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.
>
> 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 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.
>
> 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 (I’m sure there
> will be many), and I’ll summarize for the list. Also – if you have
> any references that speak to this design, please pass them along!

18 Sep 2004 - 12:10am
Listera
2004

Ted Booth:

> #1 allows everyone to everything, but limits their access to specific
> things based on their position in the hierarchy
> #2 shows users only 'what they need to know'
>
> From an operational management point of view, #2 is probably the better
> option.

Yes, unless you're also managing expectations.

Imagine Toy's R Us stores had invisible detectors at the entrance that could
silently read the amount of money in your pocket. Then, when you got into
the elevator with your kid, it took you to the floor designed to sell no
items beyond your purchasing reach. It would be a marketing fiasco.:-)

Ziya
Nullius in Verba

18 Sep 2004 - 8:46am
Dan Saffer
2003

Unless there is some way of moving between roles (by switching modes or
buying the full version of the software, say), there is little point in
showing people what they can never have.

An exception to this would be if the lower-permission users would need
to communicate something to a user with more permission. e.g. "Bob, you
are going to have to add another user to the system." In which case,
showing the users all the options that might be available isn't a bad
thing.

Dan

21 Sep 2004 - 4:35pm
cfmdesigns
2004

It's really going to depend on how the state of the system changes over time.

If a user is presented with commands which are disabled (grayed),
they will have a tendency to look for ways to enable them (or at
least think about that). "What context do I need to be in to get
that command to work?" If this state change isn't something which
can occur easily and within a single session of the application, then
you are just giving them garbage, distractions, and tease: look at
all these great thing you can't use, neener-neener!

Also consider whether a change in state which would allow access to
other commands shifts to an entirely different set of commands or a
superset of the first set. If the second-level users is going to
have both a bunch of new commands available and a bunch of previous
ones no longer available, you might as well not do any dimming.

Another tack would involve whether the set of commands a user sees
will change back. If someone transitions from State A to State B but
never (or very rarely) comes back to State A, then keeping the State
A commands showing after transition isn't of use.
--

----- ----- ----- ----- ----- ----- ----- ----- ----- ----- -----
Jim Drew Seattle, WA jdrew at adobe.com
http://home.earthlink.net/~rubberize/Weblog/index.html (Update: 07/20)

21 Nov 2004 - 11:13am
Will Tschumy
2004

>
> Hi All-
>
> I'm the User Experience Architect for a suite of back office
> applications. We've struggled with this very same choice. In the
> end, we decided on implementation 1 for several reasons:
>
> - The differences in the roles are really the ability to view field
> level elements, edit, or submit - the user flows through the system,
> however, do not change with different user roles.
> - Our applications are very complex, and as such, the role
> configuration is a 'nuanced' thing. Inevitably, there's a lot of time
> spent on tweaking the capabilities of each role / group assignments,
> etc. We needed users to be able to see all of the options, so they're
> able to tell support that I need access to field x, on page y.
>
> We found this approach worked well. What we also found was that a
> better area to spend both UE and engineering dollars was on the
> interface that maintains the individual role permissions.
>
>
> Thanks. Will.
> On Sep 21, 2004, at 5:35 PM, Jim Drew wrote:
>
>> [Please voluntarily trim replies to include only relevant quoted
>> material.]
>>
>> It's really going to depend on how the state of the system changes
>> over time.
>>
>> If a user is presented with commands which are disabled (grayed),
>> they will have a tendency to look for ways to enable them (or at
>> least think about that). "What context do I need to be in to get
>> that command to work?" If this state change isn't something which
>> can occur easily and within a single session of the application, then
>> you are just giving them garbage, distractions, and tease: look at
>> all these great thing you can't use, neener-neener!
>>
>> Also consider whether a change in state which would allow access to
>> other commands shifts to an entirely different set of commands or a
>> superset of the first set. If the second-level users is going to
>> have both a bunch of new commands available and a bunch of previous
>> ones no longer available, you might as well not do any dimming.
>>
>> Another tack would involve whether the set of commands a user sees
>> will change back. If someone transitions from State A to State B but
>> never (or very rarely) comes back to State A, then keeping the State
>> A commands showing after transition isn't of use.
>> --
>>
>> ----- ----- ----- ----- ----- ----- ----- ----- ----- -----
>> -----
>> Jim Drew Seattle, WA jdrew at adobe.com
>> http://home.earthlink.net/~rubberize/Weblog/index.html (Update:
>> 07/20)
>> _______________________________________________
>> Interaction Design Discussion List
>> discuss at ixdg.org
>> --
>> to change your options (unsubscribe or set digest):
>> http://discuss.ixdg.org/
>> --
>> Questions: lists at ixdg.org
>> --
>> Announcement Online List (discussion list members get announcements
>> already)
>> http://subscribe-announce.ixdg.org/
>> --
>> http://ixdg.org/
>>
>>
> For wct at mac.com
> -----BEGIN PGP PUBLIC KEY BLOCK-----
> Version: PGP 8.0.3
>
> mQGiBEAqjKYRBADzC8wAAb1rV70+yqaKPgRoozodNrUcZ4iK6OOrVTNjxml1EBFe
> Fle7/RhQakHId5g0bvo3CwsilyxyfN0KvcVkSfqDabrBxota5UR/SPLZyMENSR2G
> QQ0b2beG2m+ZsVWyMbJ/TDRMVGj5k5DSdRpCPWYg762yemAQfH2tZ6M8BwCg/3/E
> CI3SxCiHDrjTQ6PZxQ1HlYkD/1ShweAlJfPmPTvns5Meqcg3qBAmW43BA/na/jfs
> Y71lG/BkoysZeVKcoQ87W6EUOOOoSes8kxU4fjRAzIONaNXOE8KK9pQrZwNEHz32
> UEUiKAijpNfBVPwEAIgOIOk6gm4X+TY6wZYe61RO0suP9I7YwwlxGkX9MsXP/53b
> eGB1A/9COSiVGqgyjUU5tBHZxLjxt1If1cV6VPPA8n2O7BAySPCp2TBqmcqeS0ma
> NJ0hbtloHMoggAHzAk7un63U0UhcZokEDv4pjXzAfGyloowwiBKUXhPH7qZ0+Edb
> iBtRXCrfXMowzkeab/xZ157OcSzegynqJPT7cJa7XUjxQRm0V7QdV2lsbGlhbSBU
> c2NodW15IDx3Y3RAbWFjLmNvbT6JAFcEEBECABcFAkAqjKYHCwkIBwMCCgIZAQUb
> AwAAAAAKCRCFmwMzVcUAqGqSAJ99RTS2+aE3DSBe0r9E0FftMaSd2wCePmRVUTFV
> c64fXdCuMtCDcviOwLe5Ag0EQCqMphAIAPZCV7cIfwgXcqK61qlC8wXo+VMROU+2
> 8W65Szgg2gGnVqMU6Y9AVfPQB8bLQ6mUrfdMZIZJ+AyDvWXpF9Sh01D49Vlf3HZS
> Tz09jdvOmeFXklnN/biudE/F/Ha8g8VHMGHOfMlm/xX5u/2RXscBqtNbno2gpXI6
> 1Brwv0YAWCvl9Ij9WE5J280gtJ3kkQc2azNsOA1FHQ98iLMcfFstjvbzySPAQ/Cl
> WxiNjrtVjLhdONM0/XwXV0OjHRhs3jMhLLUq/zzhsSlAGBGNfISnCnLWhsQDGcgH
> KXrKlQzZlp+r0ApQmwJG0wg9ZqRdQZ+cfL2JSyIZJrqrol7DVekyCzsAAgIH/1Dk
> g4oUopmYfH7xrkBR7fg5fDS793a9jIja4cm0tuEW5E2x8oo7qwerhGX60kw1oQxA
> anvnFhzZYc2CKeswjC7TjRvKHg/JHaMJcH6SBA2ZfcZgWHUvIdu+xtSz+p47zz40
> YXVKekTC6EJJ1OgWiAIEQuIF8cFxpSYHFCu9zQitQgwxGDsBpF6BRDr0VDQvJi0e
> lf48tXfQ3SEzuhHS8cOXnpWuQBAFGA3G194/1UETuOd3YZolc7DAaoUqQZ3hP0S+
> W+JerJZnVfQoyXsGsDytFNKgmMf+cieWH6+olktdmxf/R5G6d+mAMQJ3twOihBjh
> A3LzlCQ5tYwgeev2zEOJAEwEGBECAAwFAkAqjKYFGwwAAAAACgkQhZsDM1XFAKgg
> uQCcCvU7RZOTm2TcG907ALfKMQU1UD4An3iKk7UpWhU4OuhqFUnR+uFc5QUe
> =uUeF
> -----END PGP PUBLIC KEY BLOCK-----
>
>
for wct01 at earthlink.net
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: PGP 8.0.3

mQGiBEAqjm0RBAD28/HeQhyPnGjop1etuJTIMKAqEA0bcqNRApTxIxk3H9JnjHnE
ZOcIbq85KFdvKe7E5SkApZKzDsnSVOc180eFwRiAGE3aYi/ueOpeSqpiKLHj0zo1
yOP3f1QwhWYU5S0fBfTaSOidjneeRLFQ+NB2phXP2AyZU97wlAdRMA2/KwCg/zfc
juDFvzeHhEjXRSQXKEqY4+sD+wdI9air24wi97y3QNyQitBsyts25O0yCqgU0iEh
y62baTyOxi1VEVxveUAJNTnK7GILzTICYBOrX5NpQgBmWAEpC15oSMWYHb2UyTZm
3NbVihhVuWkCcY1L8Ik5jehRb0JyB0Cvp3dsLNjJouiFu10iMkVqjGQKadjCpGUZ
Zo40BADiG8V0lWZym8yQ67/lN7x3urB6TpFPH6sUbxQZESQwPnMKCdDHWEEyuL2M
rr/yJwrK+7vsnkLP1fYNS7ajCfYeH7832vuU1nbUFkLvLCeXS5DtHozYr6/hwqNy
io+3ECzsLc559n77REjEEvFNyNVoZvLx5a56mQzKXmz+EmcGrbQlV2lsbGlhbSBU
c2NodW15IDx3Y3QwMUBlYXJ0aGxpbmsubmV0PokAVgQQEQIAFwUCQCqObQcLCQgH
AwIKAhkBBRsDAAAAAAoJEIutTxYy9L9NJkYAoJNVHv9YqLbDrQoVqV3cs0prPtxT
AJYiveL5DQcAkhqIl3YPtnAMTrRTuQINBEAqjm0QCAD2Qle3CH8IF3KiutapQvMF
6PlTETlPtvFuuUs4INoBp1ajFOmPQFXz0AfGy0OplK33TGSGSfgMg71l6RfUodNQ
+PVZX9x2Uk89PY3bzpnhV5JZzf24rnRPxfx2vIPFRzBhznzJZv8V+bv9kV7HAarT
W56NoKVyOtQa8L9GAFgr5fSI/VhOSdvNILSd5JEHNmszbDgNRR0PfIizHHxbLY72
88kjwEPwpVsYjY67VYy4XTjTNP18F1dDox0YbN4zISy1Kv884bEpQBgRjXyEpwpy
1obEAxnIByl6ypUM2Zafq9AKUJsCRtMIPWakXUGfnHy9iUsiGSa6q6Jew1XpMgs7
AAICB/0Zz7j3QcmHtW8Uo71oUYQE18EzvbPIRW57moNSMW8C7VnPZWVMtYBRITqG
A4uLBMxNrmel7ytgFBrFDnGv4JfojRuUXCtX7kXNytDk26l982/iK0y6taBSCdqt
wrEpIR9K3paRGZvshGeCsFKl0FO1RWYltfwFfsY3dg/21KXi4lBo2PteZOeg/YUU
TvJi4y6p2Iauxww59io4jnw7uQdXDNsJsXE4htb396Pfcumu6H+Mjb2kAFz6l+nl
Iv6g8xMWqfLOTb4mt3yHwM9J/S74wHmzbh6U8xPorfPOWhftDWWSEB+Tq8Q8YysT
46WdJjUPuPZRarId8z4rDn33Seq+iQBMBBgRAgAMBQJAKo5tBRsMAAAAAAoJEIut
TxYy9L9NiuYAn2onSerK0LhL5elUeYM7J7BGJcy9AJwN1mDqz2ri1aRXpNR4eB82
VPpDMQ==
=Cv53
-----END PGP PUBLIC KEY BLOCK-----

Syndicate content Get the feed