One of the things I like about gov.uk is that if you spot a little glitch and ask them to fix it, they probably will. Even better, they make it easy to do that by having a feedback link on every page, thus encouraging behaviour which is to the benefit of all.
Another thing I like about gov.uk is the way it embodies its design principles, and in particular the clarion call to design for the needs of users:
The design process must start with identifying and thinking about real user needs. We should design around those — not around the way the ‘official process’ is at the moment.
There is nothing new about that as a principle, of course, but the fact that it has taken substantial iterations over many years to get even as far as we have demonstrates how hard this is and how much further there is to go, as well as how far we have come.
One of the hardest things for people with a conventional service provider mindset to get their heads round is the idea of a customer journey. It isn’t the idea of setting out the stages from the customer’s point of view which is the sticking point in my experience – that’s conceptually clear even it can be very hard work to do (Stephen Collins has just published a set of actor-focused design questions which shows very neatly how far beyond the obvious it is necessary to get). The sticking point is very often the apparently simple question of when a journey starts and when it ends. Service providers overwhelmingly set the starting point too late, and almost as often set the finishing point too earlyService providers overwhelmingly set the starting point too late, and almost as often set the finishing point too early. The first thing that happens, they might say, is that the customer calls our contact centre, not spotting that from the customer’s point of view that might already be a long way into the journey. The last thing which happens is that our actions are completed and we have done what we were supposed to do for the customer, not spotting that in many cases that is only one stage of a process which has no meaning to the customer until the wider process of which it was part has also been completed.
Here’s a simple example. A few days ago, I happened to notice that a link on the Foreign Office page on gov.uk appeared twice. No great harm done, but worth tidying up, so I reported it. Within a couple of hours, I had a response telling me that ‘your request has been resolved’. Impressive. Except that they didn’t actually mean that at all, they meant ‘your request has been sent on to some other people to deal with, but we are marking it done as far as we are concerned’. ‘Resolved from the point of view of the gov.uk helpdesk’ turns out to mean something quite different from ‘resolved from the point of view of the service user’.
What that tells me is that the apparent unity of gov.uk still masks the underlying organisational fragmentation of government. No real surprise there. But it also tells me that second order services both matter and may unintentionally illuminate something about the gap between perceived and actual customer journeys – and about how much flapping is going on under the water.
This example is, of course, trivial – I wasn’t stopped from doing what I needed to do, the glitch has now been resolved, even if not quite as quickly as GDS suggested and it wouldn’t have particularly mattered if I had had no feedback about resolution in any case. There are clues that at some level, the problem is recognised. I may well be reading too much into it, but the fact that they tell me the 
problem has been ‘deemed solved’ rather than just ‘solved’ suggests some understanding that closing an incident is not the same as resolving a problem. But these kinds of breakpoints are surprisingly common in my experience, and it’s worth reflecting on what that tells us.
It can be surprisingly easy to overlook that you are designing a service at all, and that you need to understand the underlying customer journey. It can be surprisingly easy to overlook that you are designing a service at allIt is all too easy to see how designing a helpdesk system could fall into the trap of focusing on how cases are managed and resolved within the organisation at the expense of focusing on the customer experience it delivers. Even with perfect awareness, keeping to the users’ needs is harder than it looks. It may be the first principle, but it competes with other demands. In the end, choices and trade offs have to be made, approximate and off the shelf may trump perfectly targeted and hand crafted.
More importantly for the long run, it shows in a small way that however apparently well integrated your front end, fragmented back ends will always get you in the end. If as service providers and service designers we allow ourselves to focus too much on the former at the expense of attention to the latter, the cracks will become more apparent and more real. As gov.uk increasingly embraces transactions as well as information, preserving the unity of the customer journey in a world where more than one provider is contributing to a service will become increasingly important.
Leave a Reply
You must be logged in to post a comment.