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 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. It 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.

Computers are dumb. Humans are smart. So it makes sense for computers to do as much of the smart part as possible and leave the humans to cope with what the computers can’t do.

Sometimes that is most obvious in little things, such as entering information in ways which any human could make immediate sense of, but which brings badly designed software to its knees. Enter a date, a credit card number, a post code. All simple things, all things which have been part of web forms since the dawn of internet time, and all of them badly done with remarkable frequency.

I had a rant about that several years ago (which opened with a rather smug passage about how I had avoided that particular trap on the one occasion on my life when I have had to put any of this into practice). As I observed then,

There are things humans are good at, and other things which computers are good at. Putting simple data elements into standard formats is, without a shadow of doubt, something for computers, not humans

In the four years since then, depressingly little has changed. Just yesterday, a site asked me for my credit card expiry date, with a lovely wide field to type into. “03/14″ I typed (or something on those lines) and carried on to make the payment. “Your payment card has been declined” was the stern warning in red at the top of the next screen. By which it turned out they meant that the card expiry field, though occupying half the width of the screen, was limited to four characters. So my entry had been truncated to “03/1″. It then stripped out the “/” and submitted “031″ to the card processor. What it had wanted – and the only thing it would accept – was “0314″. The most trivial of cleaning up would have got to that from what I gave them, and they clearly have the code to strip out “/”; it’s just not deployed in a way which gets the balance right between humans and computers. And if they weren’t up to doing that, just making the data entry field four characters wide would have given me enough of a clue.

So it’s worth celebrating the people and sites who take the trouble to get this right.

One of the many reasons why I like Matthew Somerville’s Train Times site, apart from being the best way I know of discovering where trains are supposed to be and where they actually are, is the simple elegance of the data entry – throw pretty much anything at the date field shown on the right, and it will cope.

Now, from another corner of mySociety, comes a brilliant post by Dave on why all this matters and how to understand the design problem which actually needs to be solved. It isn’t really about the near-infinite set of ways of referring to dates and times, it’s about recognising that some forms of complexity are best moved away from users (who get frustrated and irritated) to computers (which don’t). Doing that successfully entails thinking about what users want to do even (perhaps especially) when they have to do something as simple and obvious as typing in a date:

The general rule is: even for something as simple as this little web form, if it’s possible to create an interface that matches the way that a user thinks about the world, then it will be less confusing for them than one that does not. Usually this means the system has to be a bit more complicated to program, in order to convert what the user types to what the computer needs.

Once you start looking for them, there are lots of examples of small details displaying thought, wit and imagination (as well as occasional tweeness) – and a site dedicated to collecting and displaying them.

So let the last word go to Dave, from another of his posts:

If you want to build sites that people use, you should be as clever as a magician, and the secret to that is often keeping it simple — deceptively simple — on the outside.

You are walking down the stairs in an office building. At each level, there is a sign on the door to tell you where you are. Quick, which floor are you on?

The fact that I asked the question probably made you look more closely than you would otherwise have done, so spotting that the right answer is 3, not 5. But all the visual emphasis is on the 5 – from more than a couple of feet away, that’s all that really registers.

Knowing which staircase is which clearly matters to some people for some purposes – being able to specify where a light bulb needs fixing, for example.  For almost all people for almost all purposes, it does not matter at all.  The only piece of information which matters is the floor number – and that matters a lot.

It is hard to think of a simpler example than this one of how a user interface could be improved.  But the real lesson is perhaps not that it would be better to make the 3 big and the 5 tiny or non-existent on that sign – though undoubtedly it would be – but that there is something about the process which led to the wrong answer having been reached in the first place.

My guess about this one (and it is only a guess) is that users were involved in the decisions about the signs, but that they were the wrong users.  By unhappy coincidence, the people responsible for putting signs on staircases are precisely the people for whom the non-standard use of the sign matters most, because they are also the people who fix the light bulbs.  They have, it appears, treated themselves as typical customers.

I have seen the same mistake made at much greater expense and with much more serious consequences in much bigger and more complicated systems than this. When specialised users are in a position to specify a service to meet their needs, that is what they will do, even if they are a small minority of the overall user base.

We may be users of the services we design.  But we are not the users we should be designing for.