A new e-petitions site for government was launched yesterday. It is clean, simple and elegant, with clear government branding consistent with other cross-government sites. So far so good. But managing a cross government service is a tricky business, for reasons I have explored before. Government is a veneer that sits above departments, and like any veneer, can easily crack if the underlying structure is not firmly held together. If you want to understand why government online services so often feel as though they are not quite all that they could be, this is an example worth reflecting on.
An eager e-petitioner clicks the button to start the process and finds themselves with a simple form to complete. The first task is to give the petition a title. Pretty straightforward. The second is to identify the ‘Department that looks after your issue’. That’s a poser. There is a drop down list. There is a link to a page which explains which department does what. But the list is of ministerial departments and the help page gives little more than mission statements. Many of the bits of government which people have at least some understanding of don’t appear at all – there is no HMRC, no DVLA, no NHS, no Jobcentre Plus. Might a petition be appropriately directed to the Scotland Office, or should it go to the Scottish Government instead?
So I wrote a slightly frustrated tweet:
#bbpBox_96851442098376704 a { text-decoration:none; color:#38c4d9; }#bbpBox_96851442098376704 a:hover { text-decoration:underline; }
And got a response I have a degree of sympathy with:
#bbpBox_96852213485412352 a { text-decoration:none; color:#c34242; }#bbpBox_96852213485412352 a:hover { text-decoration:underline; }
There are parts of any interaction where the user is expert, and there are parts where the provider is expert. One of the keys to good service design is to ensure as far as possible that each does the right bit. Asking petitioners to map petition subjects to government departments fails that test.
There are parts of any interaction where the user is expert, and there are parts where the provider is expert. One of the keys to good service design is to ensure as far as possible that each does the right bit.So why does it work like that? I have no inside information, so can only guess, but the answer might come from asking what might have to be different to make the problem go away.
At a first glance, there are two basic ways that might be done. The first is to attempt to use the petition itself to answer the question. A little bit of keyword analysis, a touch of natural language processing and the job is done. That would be in the spirit of the approach, and the suggested destination could then be reflected back to the petitioner for a human check. The second would be not to bother at all at this stage: just send them all to somebody whose job it is to do the routing. There is also a third which wouldn’t make it go away, but might reduce its impact, simply to ask the question later and avoid its jarring position between petition title and petition description.
The problem with the first is that it makes a simple thing much more complicated. Essentially, the e-petitions site is a simple web form. That’s a feature, not a limitation: the project was designed from the outset to test and demonstrate an agile approach, where finding ways of making things simple is critical to finding ways of making them happen at all. Adding on the kind of analytical tools to add intelligence to the routing might have slowed things down a bit – but might well have stopped progress altogether.
The problem with the second is that it risks introducing a cascade of consequential problems. There is nobody whose job it is to do this kind of routing, because this kind of routing is not done. So a role would need to be created, made part of a team, attached to an organisation chart, found a desk, found funding – not just for this year but for next year, and the year after that. There is nothing more to that, in a sense, than the issues any project has moving its creation into live running, but in a different way this too might have slowed things to paralysis (though reading the site’s terms and conditions shows pretty clearly, that some of that is needed anyway: if ‘it will usually take up to seven days from the time an e-petition is submitted for it to appear on the website’, the back end is human – and if one of the humans could reflect on the use of ‘usually’ and ‘up to’ in that sentence, the world could easily be made a better place).
All that perhaps boils down to saying that it is is better to have something now rather than something potentially better in a future which may never be reached. That’s not a bad argument, but in this case at least, I think it is wrong.
It is increasingly, and rightly, said (including by me) that there is no such thing as an IT project: there are only business projects with IT components. The corollary of that is that there is no such thing as an IT solution, there are only business solutions supported by IT. A solution is not a solution if it does not support the right overall experience and outcome. The e-petitions site is partly about e-petitions, partly about showing what a skunkworks can do, and partly about pointing to the future of government services. It has done the first two admirably. I am not sure that it has done the third.
Leave a Reply
You must be logged in to post a comment.