Access online government services
Problem
Civil servants working on operational teams or building services use multiple government as a platform (GaaP) services each day.
Each of these services has access restricted and requires users to have an account.
It frustrates users to have to manage many accounts and log into each service separately. Often, they have to log in during a task that requires them to use more than one service.
Managing these accounts is frustrating for civil servants and an operational overhead for platforms.
What
As part of the Government-as-a-platform initative, we ran a short discovery and then an alpha to explore a potential solution to this problem.
Identifying the core needs of our users
We identified 2 key user groups whose needs we had to meet.
We had users accessing services. So users, who as part of their jobs need to access a number of platform services.
And we had users building these platform services. So users that need to control access to the service they are building.
We did extensive user research, speaking to over 80 users across government. This helped us to understand the nuances of their needs and the context they worked in. Each department has their own IT setup, processes and environments, each of which we need to understand and considered when designing a solution.
Simplifying complexity
The solution we were working on was technical.
It was a technical solution to a technical problem. In a problem space that was heavy on abstract terminology, such as Identity.
It was important we could explain our solution to stakeholders and service builders.
I led on an activities to simplify how we explained and communicated our work.
I designed a series of diagrams to help explain the architecture and how we planned to integrate with the different services.
How visible should the service be?
A key challenge was figuring out how visible the accessing a service journey needed to be.
Logging into a service is a bumpy journey, it often breaks the flow of a user. This project ran in 2016 when people were less experienced with login mechanisms such as single sign on. Users’ mental model was you sign in on the service you are trying to access. Our solution took them away from the service they were logging in to.
This meant, we ran the risk of increasing the friction and cognitive load users experienced when logging in.
It was important we kept users informed and managed them through the journey. We wanted them to know what was happening and why.
I designed multiple iterations of the journeys that we could test with a wide variety of users. This allowed us to find the right balance between giving users too much information and making it feel less jolting.
Recording progress
I used a tool, initially created by Tim Paul, to record how the prototypes changed over time. And, annotated the screenshots with the key findings from research.
This tool came in handy when we took the project through an alpha assessment.
Planning for different situations
Our research showed us the differences between different GaaP services and department IT functions. We realised early on that we had to make sure the solution would work for each of these scenarios.
This would give it the best chance to succeed.
Some GaaP services were further down the path to delivery than others. This meant they had existing users. Other services were much earlier in the process. Therefore, we would be able to work with them during the implementation stage.
Some departments had “identity” solutions we would be able to piggy back off. This would leave "identity management" in their hands. For other departments we would need an alternative so we created the idea of an “IdP of last resort”.
Outcome
We designed and tested a solution to the accessing government services problem. We took a technically complex solution and made it simple for platform teams to adopt and roll out, and simple for end users to understand and use.
We passed an alpha assessment and prepared the project to be built out in beta stage.