“Citizens Portals” are all the rage, but are they any good? TL;DR — No. No they’re not.
The main problem is that the products being sold as citizen portals are not intuitive for users and are designed around business processes, not user needs. “I really wish I had one place where I can see all my transactions with the council”, said nobody, ever. In all the workshops, co-design sessions and user interviews FutureGov has done over the last eight years no one could recall anyone expressing that kind of need.
What a council *does* need is a good data platform that means they know who a user is, wherever they transact, but this doesn’t need a front end for users, just good back end integration and a decent CRM — breaking down single solutions into their constituent parts to use in combination across different use cases.
Broadly, user transactions can be split into three groups:
- One-off or rare (e.g. when you’ve just moved to the area, or applying for a school place, or planning application)
- Regular renewals (e.g. parking permits)
- Accounts (e.g. benefits and housing rent)
The first two don’t require an account if there is decent integration (e.g. you don’t need an account to renew your vehicle tax, it identifies you each time — the same should go with parking). If you’re telling the council something (like a change of address) you shouldn’t need to see that in an account, just submit and get a confirmation email. They’re ephemeral, easily forgettable transactions.
Planning/school applications might need the ability to return to your application but I’d argue they’re two separate task-based processes, rather than one big Citizens Account (why would I want to view my planning applications when I’m trying to get a school place?).
There’s an argument for a housing/benefits/social care account because the two go hand-in-hand usually and users are likely to return to the same information regularly. This is a collection of stand-alone apps linked by single sign-on because there is a user need for reviewing your account history, seeing progress and updates. To make this work we need to think about what data each service would be capturing and how and where that data could be shared. If that is a principle going forward then we can start to connect where we are collecting the same information for different services and where we could use that data (with the users’ permission) for that next transaction.
The main problem that citizen portals seem to be trying to solve is authentication, but there are plenty of Oauth2 solutions out there that don’t put users through a portal experience. The Government’s Verify service will allow a micro-service structure while letting verified users do all sorts of transactions (so even capturing who is making one-off or rare payments or renewals) but that seems a little way off. There are also other ways of remembering certain data, for example storing in cookies during a session.
The priorities should be:
- The insistence of open standards of your suppliers which the sector has to get better at — you’re in charge, lean on them.
- An amazing content management system that gives complete ability to redesign the front end so that the user experience of transacting with the councils is an elegant experience
- A backend that allows you to access the data from the CRM (e.g. case management systems) and store this in one place
- Doing the integrations necessary to make transactions seamless. Here we’re talking about APIs rather than a single integration product.
- Now that you have access to all of this amazing data, employ people who know what to do with it and understand how to analyse it to support constant iteration
The last of these just might be the hardest to do.
There is also a lot of talk about a “Golden Record” — a single view of a customer — but again, the customer doesn’t necessarily need this, it’s a business need. Sharing details between account transactions (council tax, benefits, housing rent) is totally possible without putting every council transaction behind a login wall. Data and systems are not linked — your ID, your login, your data and the interfaces you use are all separate elements loosely joined.
As an aside, there is no good example of user-centred design on citizen portal interfaces — onboarding users to the portal takes ages and costs money, which goes to show how little thought has been put into the user in these systems.
Ultimately, of course, it’s about building services, not transactions — meaning a seamless user experience and customer journey is vital otherwise there’s no point messing around with systems and data.
Watch GDS explain these concepts through the medium of Jenga blocks.
FutureGov is working on a new kind of case management system using this approach, and building on our co-design work on ChildStory in Australia.