We’re integrating One Login into our services so that it manages user accounts for us. We control user permissions to access different services. We then associate the user’s permissions to their One Login account using their email address.
To do this, we changed our ‘add an account’ journey to ‘add permissions’. Manager users will need to add permissions for each user of our services so that they have the correct access.
You can see the previous journey to add accounts in our prototype. The password is: proto
It’s from the viewpoint of someone working for Bristol City Council.
Setting permissions
Our users could work in a local authority or in a voluntary and community sector (VCS) organisation.
Initially, the Department for Education will create accounts for local authority users. When they set up those accounts, the service asks which local authority the user works for. Once a local authority user has an account, they can create accounts for:
- other people who work for their local authority
- people who work for VCS organisations in their local authority area
We do not need to ask which local authority the user works in because we know this information from the person setting up the permissions.
We have two different types of permissions. These allow a user access to the right service:
- Manager users can add to and manage the directory. If they work in a VCS organisation, they can add and manage their organisation’s family support services. If they work in a local authority, they can add and manage their local authority’s services and family hubs, and add permissions to other users’ accounts.
- Professional users can manage connection requests. If they work for a local authority, they can send connection requests to voluntary and community sector organisations. If they work for a VCS organisation, they can accept or decline those connection requests.
The new journey to add permissions is in our prototype. The password is: proto
It’s from the viewpoint of someone working for Bristol City Council.
Switching from roles to tasks
The previous account creation journey used our language. Internally, we refer to user roles as ‘professional’ and ‘manager’. Users with the ‘manager’ role add and manage family support services and accounts. Users with the ‘professional’ role manage connection requests. These labels are entirely made up by us. Users do not need to know how we refer to these roles. They are not what users call themselves.
For the new permissions journey, we switched the way we ask questions to find out what kind of permissions we should assign. Instead of asking ‘Who is the account for?’ and giving people ‘manager’ and ‘professional’ options which include where they work, we’ve split the question in two. We now ask:
The options here tell us whether the user works for the local authority, or for a voluntary and community sector organisation within the local authority area.
These options tell us whether they’ll need to access the manage family support services and accounts, or to manage connection requests.
For the moment, we’re recommending that only one user per VCS has permissions to manage connection requests. This is to avoid potential issues with users assuming that connection requests have been responded to by others. However, we understand that this might not always be possible, so we’re keeping it as a ‘should’ rather than a ‘must’. We’ve used hint text to make this recommendation:
Collecting users’ details
As mentioned, we need a way for GOV.UK One Login to recognise users’ accounts. We collect each user’s email address to do this.
We also ask for the user’s full name. This does not need to match their One Login account exactly, and it’s the only piece of information that they can change within our service – the rest they change within One Login.
To collect users' names with GOV.UK One Login, we’d need to use the One Login journey where users must verify their identity. We decided that’s more than we need and would make the permissions journey too complicated. We’re now collecting names directly within our service.
We also ask for the VCS organisation, if the permissions are for a VCS user. We use the accessible autocomplete component to match them to an organisation already in the directory, added through the add an organisation journey.
Simplifying the journey
user at a time. That meant when setting up account permissions for VCS users who needed both types, users would have needed to go through the journey twice.
We were not happy with this, because it felt like it would be easy to think it’s finished once you’ve been through the journey once. Meaning some users may only get half the permission they need. That would mean connection requests could be disappearing into a void, never to be picked up.
We changed the journey from a ‘once per permission’ model to ‘once per user’ model. Now, for adding permissions to VCS users we use checkboxes instead of radio buttons so that the person adding permissions can select both types and only needs to go through the process once.
Telling users what happens next
In the previous account journey, we used a confirmation page banner to say ‘details confirmed’. Now we’ve changed this to a permissions journey, the banner reads ‘permissions added’. We’ll see how this tests in user research, but we felt this was a better reflection of what a user has just done.
Adding permissions sends an email to the user who now has permissions added. The email:
- tells them they have access
- contains a link to the start page of the service they have access to
- explains that we use GOV.UK One Login, and, if they need, how to set up an account
We’re still working on our start pages, and we’ll test the emails and start pages in future research.
Future considerations
We know this journey is quite a change from adding accounts, and we need to see if it works for users. We have user research sessions planned where we’ll test this, and we’ll iterate based on user feedback.
We’re also planning to collect ‘team’ information for users making connection requests, but that’s planned for after our MVP design. We’re collecting information from user research about how we build this, including:
- what level of detail people responding to connection requests need
- how the added functionality will be used in the ‘manage connection requests’ dashboard
- whether we use free text or structured answers taken from the database
We’ll update this design history post when we add this into the journey.