We recently completed a discovery on signing in, and managing access, to digital services. Three weeks in, the discovery forked in a very different direction - one we didn’t expect - which I’ll explain in my next post.
In this first blog post I’ll set the scene, explain our initial user research approach and share what we learned.
What we learned from the hackday
In January Government as a Platform (GaaP) held a hackday, for teams from across government to come together to try and build services using GaaP components. As Rory Smith explained we learned a huge amount about our users, but it was clear that our account creation processes weren’t as seamless as they could be - some developers were waiting hours for their credentials.
For GaaP products, the government design principles very much apply - not least ‘build services so good that people prefer to use them’. And in the case of developers and technical architects, we need to take that seriously. The usability and simplicity of GOV.UK Notify or GOV.UK Pay should far outweigh those of other products, so that teams are keen to use them.
Since the hackday, the GOV.UK Notify team has made huge improvements to their sign up process and sent out its first high-volume batches of text and email messages. GOV.UK Pay has achieved PCI accreditation, and ‘Platform as a Service for government’ is hosting the Trade Tariff service. Each of these products has a large pipeline of services waiting to use them.
These services were built discretely: each has its own user database, needing a separate username and password. We were concerned this may slow developers down and create headaches for civil servants managing multiple sign ons. We needed to do some user research to see if that was true and, if so, what we could do about it. So we:
- talked to the GaaP product teams to understand their pain points and user needs
- talked to GOV.UK about their Signonotron service
- visited Pension Wise who have reused Signonotron for their own suite of services
- visited DWP in Leeds who are piloting the use of the NHS’s own identity services to sign forms for Personal Independence Payments
- visited the MOJ’s ‘Send money to a prisoner’ service team to understand how they use GOV.UK Pay
talked to the Digital Marketplace service team about their use of GOV.UK Notify - ran a workshop with the Lasting Power of Attorney service team
How different user groups manage access to multiple accounts
This user research showed us, slightly unexpectedly, that logging in wasn’t currently such a huge and new barrier to uptake for developers wanting to use GaaP services.
That’s not to say that operational staff aren’t frustrated by managing multiple user accounts; they are, particularly on services where they have to log in frequently. Workarounds for this proliferation can have security implications.
However our user research highlighted how differently developers (the people who first decide whether or not to integrate with a GaaP service) tackle the issue of multiple sign ons. For example, to register with a service such as GOV.UK Notify, they get their API keys, and then log out so they can continue making software. They don’t do operational work that requires a daily login. If they were integrating multiple GaaP services, or started to log in more frequently, they’d use tools like password managers to remember their passwords for them.
The two operational services we met (Digital Marketplace and ‘Send money to a prisoner’) had different models.
One service has a small number of users and transactions. Staff log into both their service and GOV.UK Notify at 9am, then transfer files between the two tabs throughout the day. API integration is coming, but it’s not a burning problem.
The other service has a very large number of operational users using the main service, interacting with GOV.UK Pay through APIs. Only a tiny proportion also need to check the GOV.UK Pay administration interface, having two logins for different parts of the service.
Creating a test service to get more insight
During our alpha we need to talk to a lot more services that may want to use GaaP products. If large numbers of operational users need to regularly log into (and get logged out from) two parts of a service, then this will affect our roadmap.
It’s worth noting GDS had approached many of the service teams that were early adopters of GaaP and helped them onboard. So, to create a more realistic experience we created a small test service that used GOV.UK Notify, GOV.UK Pay, running on the digital hosting platform ‘Platform as a Service’ for government.
This uncovered some really interesting wrinkles in the onboarding and engagement processes for each of the different services. For example, we found a broken contact form in a forgotten, but high-ranking blogpost; once that was fixed the onboarding process would take just a matter of minutes.
Other services were well-signposted and well-documented but weren’t responsive enough to initial email contact during the sign up process.
We shared our findings with the GaaP product teams. Our lead content designer has begun work to make documentation easier to find and simpler to use; if developers don’t find the documentation useful then they’ll never reap the benefits.
During these early weeks of our discovery, we learned logins weren’t a barrier for developers; we uncovered some necessary and fundamental fixes that needed attention; and we realised our documentation needed more work. But we also spotted some important themes we hadn’t expected, which we felt we should look at more closely. I’ll talk about those themes and the second part of our discovery in my next post.
If you’re looking at identity or ‘single sign on’ in your department or business team then we’d love to hear from you.
Follow Tom on Twitter and don't forget to sign up for email alerts.
GDS is expanding, and we have a number of positions that need to be filled - especially on the Government as a Platform team. So we’re always on the lookout for talented people. Have a look at our videos describing how we work, our vacancies page, or drop us a line.