Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Choosing or changing access levels or roles within a service #395

Open
benturner1976 opened this issue Oct 26, 2021 · 1 comment
Open

Choosing or changing access levels or roles within a service #395

benturner1976 opened this issue Oct 26, 2021 · 1 comment

Comments

@benturner1976
Copy link

benturner1976 commented Oct 26, 2021

How can we help?

I am looking to find out if anyone is working on services that need different levels of access or different role types to perform different actions within a service (think Admin, Editor or User - where someone might need to be one or more of these roles). It would be good to understand if role selection should become a standardised pattern for use across NHS services or whether the user needs are too varied.

We are working on an Identity and Access Management service called Care Identity Management (taking over from Care Identity Service) which helps manage the access people can have to a wide array of different systems within the NHS. As well as issuing the means to authenticate to those systems (normally using smartcards).

For some of our users, who look after many organisations or perform different roles (for example Admin, IT, Clerical and/or Clinical) they use the same service to perform different types of task. It is necessary for them to securely log in and select a role specific to the actions they will be performing.

What have you tried?

We have created a mechanism that will allow them to select a role upon entering into the system, replay the selected role and allow them to change their role should they need.

We started off by using what had been done previously for the Summary Care Record (SCRa) and found that there was a distinction between users with a few roles to those with many roles. The additional needs of those users with many roles being that they needed to see as many roles as possible within the screen and be able to quickly narrow down a long list (up to 1000 roles in extreme examples) to a specific role. We have tested the change role functionality as part of user testing of the service and users have been able to select and change a role successfully. We still need to look in more detail at the accessibility of auto-filtering the list of roles.

Selecting a role on entry (<=5)
image

Selecting a role on entry (>5):
image

Replaying the selected role to the user upon login:
image

Changing the role selected:
image

Confirming the new role selection:
image

Link to prototype: http://urs2-prototype.herokuapp.com/

@danjohnstonUX
Copy link

Thanks for this Ben. The examples provided are really useful and you raise some good questions around whether this is something that could be standardised across the NHS.

It looks as though the work you've done here is relevant to the Header for logged in users #192 too, so it would be good to see if anyone else using the header for logged in users has experienced the same challenges around selecting and changing roles too.

I'm dropping in some screengrabs of the work that was done on this for SCRa when I was working on it. These haven't been touched for a while now, and it looks as though the examples you provided have built on this in a really positive way, but hopefully this will help to stimulate some discussion.

Like yourselves, we initially grouped users who would have either one or many roles, though we didn't manage to elaborate this as far as you have for those more extreme cases of up to 1000 roles.

Users with one role

image

Where users had only one role, we played this back and allowed the user to confirm this before proceeding. They could also view the permissions associated with this role which allowed them to view what they could and couldn't do once they were logged in. This was more useful for users with multiple roles who wanted to check the permissions before logging in, but it didn't prevent users with only one role from logging in, and in some cases proved helpful to these users.

We also provided a mechanism where they could check alternative roles that were assigned to their profile that didn't have access to SCRa (in case they logged in expecting a particular role to grant them access, they could then check why this wasn't the case and query it with the relevant party).

Users with many roles

image

For users with multiple roles, we listed all the roles as well as the permissions which could be expanded if necessary. This tested well with users, but admittedly would struggle to handle the more extreme cases mentioned in your initial post.

Confirmation of role selection

image

Once a user had selected a role, we showed explicit confirmation that this role had been chosen. Feedback was generally positive, and users stated it reaffirmed they'd chosen the correct role - particularly if they were users who changed roles often as part of their job.

Locum pharmacist roles

image

We also had a separate pattern for users with a locum pharmacist role. Because the nature of their job means they moved between locations often, they are required to state which dispensing site they are working from when logging in with a locum role. We provided the functionality for this via an #111 Accessible autocomplete as quite often the users won't know the full name & address of the site they are working from, and may rely on partial postcode or name searches to successfully select the correct site.

As I mentioned, these haven't been updated in a few years now and I've moved teams so don't have access to any of the latest feedback or usage data around their adoption.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants