This is the final entry in a series of blogposts unpacking my opinions about the local government digital service debate. In the first post I set out my opinion that a single entity with the mandate and resource to address the common needs of the public is overdue; in the second I wondered about what that might mean from a democratic point of view; my third wondered about the distinction between building and buying services and my fourth explored how this might work in practice. I hope it goes without saying that I don’t claim to have all the answers and want to know where my assumptions are completely barmy!
In this series of posts I’m expressing an opinion. I find the idea persuasive and the need obvious for a local government digital service. I’m certainly not claiming to have all the answers! I think your position on this matter will have a large amount to do with whether you think Baroness Lane-Fox’s cry of “revolution not evolution” is as appropriate in the local context as it was centrally. I believe it is. Happily, local government doesn’t need to revolt from scratch – GDS doesn’t have all the answers but we’ve got some very useful experience about trying to bring all the things together. I think the GDS design principles are brilliant and so to conclude I’m going to think about what they might mean in a local context.
Start with needs*
*user needs not government needs
Local governments have different priorities, different political makeups, different challenges and different histories. They are all unique. And our experiences as citizens can’t be separated from the characteristics of where we live.
But are our needs unique?
The Local Government Services List says not always. It’s imperfect but it is a helpful starting point for the user needs of a resident in any given postcode: if services or information can be described in a consistent fashion then why can’t they be surfaced and accessed in a consistent fashion?
Do less
I want local authorities to focus their resources on delivering the best possible front line services. Apportioning a sizeable chunk of a budget to delivering digital in the currently patchy and often ineffectual way does not make sense.
Particularly if our needs aren’t unique then there’s no reason why the public experience of meeting them should differ.
By doing less procurement, creation or maintenance of bespoke (but duplicated) services our councils would be free to do, or at least protect, more of the stuff that changes lives.
Design with data
Exploring, and then mapping, the nuances of digital government is the foundation to GDS. We know exactly how many web domains government has registered (it’s still a lot). We found out how much and with whom departments were spending on IT technologies and infrastructure. We hunted out every transactional service and published the relationship between cost and volume as part of the Transactions Explorer.
My colleagues in the Performance Platform are working with some councils to build performance dashboards but what data there is is piecemeal and inconsistent. And before building a common anything (whether a service or a platform) it’s vital to know the digital topography of local government and to understand the total effort and cost involved with accessing local government services with the internet.
The data would be compelling.
For central government, we use the figure of 100,000 annual transactions as the benchmark for when a service is high volume. Taken in isolation very few local government services would trouble that benchmark but local government as a whole is second only to HMRC in the volume of transactions it handles. If the LGSL is a consistent set of needs then we have to aggregate the volumes to paint a fair picture and when you do that any service accessed on average 6 times a week becomes eligible (100,000 transactions a year divided by 52 weeks divided by 326 council tax billing authorities).
In fact demand in local government could be as significant as those things being built with much fanfare (and resourcing) at the heart of government. Bins might be too obvious but they’re a helpful example: in 2009 Hull’s 100,000 households reported a missed bin collection 41,000 times in the course of a year (that sounds bad but with 2.6m collections a year it’s a 1.5% error of margin). If as a nation of 26.3m households we miss 1% of bins every week then that’s 13.7m of the most rudimentary transactions every year. For comparison, self assessment accounts for 15.9m.
We need the financial data too. A recent BBC article reported that our county councils spend an average of £17m each year on IT services. It is likely that you couldn’t assume all that money would be saved by a single digital function for local government but we do not know enough to say either way. If we could consistently map the spending in every county, unitary, borough and district authority against meeting user needs then we would see the cost of delivering digital services at a local level.
Do the hard work to make it simple
As a member of the public I shouldn’t need to understand geography and council boundaries in order to meet my need, I just want to find the information out or know what I need to do to get something done. Marketing and branding of local services doesn’t matter – people judge the quality of a council on how effective its services are.
Equally, my experience sat in front of a computer, on a mobile or with someone assisting me over the phone should not be informed by the intricacies and complexities of legacy backends and particular suppliers or contracts. We have to stop passing on the implications of our procurement or branding decisions to the general public.
Iterate. Then iterate again.
One of the potential pitfalls of pooling local government’s digital talent is that you might lose the opportunities for innovation because multiple places are tackling similar challenges. This would need to be thought about carefully but that’s why a commitment to iteration is important. And it would mean that new ideas would be available to everyone rather than being restricted to the lucky few. Instead of one authority giving you the ability to access and save a Google calendar of your bin collection dates (try that with LN6 3RD) everybody could do it. Or instead of some parts of the country getting text message reminders, everyone could have them. And by using some of those hooks, local authorities would be able to preemptively inform you that your bin might be missed because of vehicle breakdown or crew sickness so that you didn’t log a complaint but were told things were already slightly broken.
And that could be for everybody.
Build for inclusion
433 websites were reviewed by Better Connected 2013, 195 of those passed from an accessibility point of view. This year 410 sites were reviewed but only 105 sites passed the same accessibility test. This is not good enough. Public services are supposed to be for everybody so accessibility should come as standard. If we designed local services fit for the whole country then we could address this once and for all, not in a multitude of patchy ways.
Understand context
Council sites and services are supplied by a multitude of different companies but more often than not the tapestry of products are not screen size agnostic. With only 1 in 3 council websites suited to being accessed on a mobile device the postcode lottery of being able to access local services at a convenient time and place is something that common services can deal with.
This becomes an even greater opportunity in meeting the needs of someone who is not at home when they need to contact the council. The relationship between unitary, county, metropolitan borough and district alters the nature of service availability and provision but the user needs underpinning them remain the same. Having joined up services, instead of building things bound by particular boundaries can get people the information they need as swiftly and elegantly as possible. People have a need of government, they don’t really care about who meets it and on GOV.UK we’ve recently tweaked the DVLA homepage to signpost DVSA services because that’s where people came to look for them.
Build digital services, not websites
People look at GDS and think GOV.UK and the discussion about a central team responsible for the user experience of digital in local government is often framed at the level of having a single shared website. GDS is more than GOV.UK and any effort to transform the way in which local government tackles this question would need to focus on similar themes of digital inclusion, assisted digital, overarching technology architecture, capability building, procurement improving and service design. If a local government digital service is to become a reality it will need leadership and a vision for revolution, not evolving existing practices.
Be consistent, not uniform
If you’ve been using a department, agency or arms-length body’s website and then it transitions to GOV.UK the experience is always going to be disorientating. However, with the consistent approach to information we no longer need to learn the language and information architecture of several websites. Moreover, as services are redesigned in line with the Digital by Default Service Standard transactional services reinforce a common design language and help people know what to expect.
At the DCLG event that prompted me to write these posts we heard from several councils were about to launch their new websites. In Kent they’ve adopted a very clear design pattern that echoes GOV.UK – this consistency will help the public to negotiate the complexities of whatever they need to do.
If local government could provide a consistent experience in access information or completing a transaction then we could start to benefit from some very exciting economies of scale in user research and be in a position to rapidly apply consistent improvements.
Make things open: it makes things better
It’s an important thing that’s often missed in local government procurement – too many systems are bought without having access to the data. This not only makes it hard to do useful things with surfacing or sharing information but it makes it very hard to migrate to a different supplier.
It’s really exciting that a number of councils are coding in the open but there is a difference between coding in the open and maintaining open source projects.
If a local government digital service is not created then there will still be a need to help the councils that aren’t building in two ways. To help them find out what’s available before they commit to a big procurement exercise but also for those who want to avoid that exercise to explain what they would need to do in order to make use of this code.
So, that’s my opinion on a local government digital service. I would be incredibly excited if it got off the ground but in its absence I know that this weekend’s LocalGovCamp, and the preceding hack event, will be perfect examples of the collaboration and innovation that makes local government one of the most interesting and exciting places to work.