Category Archives: Oblique comparisons

Turning on the tap of affordance

Posted by

3

The semiotics of plumbing is a slightly unlikely topic, but having not long ago discussed the affordance of soap dispensing, I now turn to the tricky question of how to turn on a tap.

There follows a ludicrously detailed description of an utterly trivial process. If that prospect does not fill your heart with joy, move on now. But that level of absurdity is necessary really to understand what might be going on and how it might be made better. The connection with public strategy is superficially very tenuous, but the reason for thinking about trivial questions in this way is to help us spot the same issues in much more complicated and less transparent situations. It is easy to spot when a tap has been designed in a way which makes its use straightforward and which Boiling and chilled water tapmakes it easy to get the desired result. It is much less easy to spot when a service has those characteristics (though sadly all too easy to spot when it doesn’t).

This isn’t a wholly ordinary tap. Its function is to provide office workers close to boiling water to make hot drinks and chilled water to do the opposite, and the two levers are labeled accordingly. So it’s quite important not to turn the hot tap on with your fingers underneath it (the sink separately has a perfectly ordinary hot and cold tap if that’s what you want). Most people manage not to pour boiling water on themselves, and in fact I have never heard of anyone hurting themselves that way.

Nevertheless, mysterious notices started to appear a few months ago. They referred to a safety button which nobody had ever spotted, still less used, but which on close scrutiny could be found just above the spout. Odder still, this button had no discernible effect on anything. Perhaps not surprisingly, the act of pushing a button didn’t seem to make boiling hot water any less boiling hot. Such signs also act as another kind of warning – as Don Norman put it, “if it needs a sign, it’s badly designed”.

Please note when operating for Hot Water press the Safety button firstWeeks later, the tap just stopped working. Things do stop working from time to time. After a while, somebody comes to fix them, then they start working again. Only nobody came and it carried on not working.

One day I noticed that the broken hot tap was warm to the touch, in the way a tap can only be if hot water had recently run through it. So I tried it again, but it still didn’t work. At which point the penny finally and slowly dropped.

The safety button now did indeed have to be pressed first. And this is where the fun begins. Now you need one hand to press down the lever on the top, one hand to push in the button at the side, and one hand to hold the mug underneath. That’s significantly more hands than most of us actually have. And the inevitable soon happened: now the tap had been made safer, I spilt boiling water on my hand for the first time ever.

But it gets better still. The tap levers have two positions. Press them down, and they are spring loaded. But pull them up and there is a hands-free flow of water. So a hack presents itself: pull the lever up and nothing happens. Then press the safety button, and water flows.

So if you treat the tap as the safety cut off and the safety cut off as the the tap, it all gets much easier – and can easily be done one handed.

Which of our services only work well if they are subverted?

Infrastructure, superstructure and not enough sockets

Posted by

0

It can be hard to reverse bad decisions. It can be hard to recover from having failed to anticipate the future. It can be hard not having enough power sockets in hotel rooms.

There is an old (but sadly discredited) story that the design of Roman chariots constrained the design of the space shuttle. It would be a good story if it were more true, but it’s still quite a good story even if it’s not true at all. It is undoubtedly the case that the decisions we make today will constrain the choices available to be made in the future, just as it is true that decisions made in the past constrain the choices we have today.

Sarah Baskerville didn’t like her hotel room in Dundee. I understand and have shared her frustration that power sockets are few in number and badly placed in far too many hotel rooms. But the problem isn’t – or isn’t just – cheap hotel rooms, it is that fixed wiring tends to be around for much longer than the pattern of usage it is designed to support. The most extreme case in my house is a room with eight wall sockets which between them currently power over thirty devices, but this is too is an instance of a more general rule. To adapt (I think) Brad DeLong, you need more power sockets even after you allow for the fact that you need more power sockets. The clear corollary of that rule is that you will always run out.

The wiring of a hotel room doesn’t need to have been specified all that long ago to feel grossly inadequate now (and often, in my experience, as much about location as absolute number, making short term fixes even harder).

We are used to the flexibility of software and increasingly of devices – of the superstructure of modern living. We want that flexibility to extend to infrastructure, but on the whole it can’t, or can’t without considerable expense, which amounts to much the same thing.

That isn’t a new or gadget specific problem. We can’t have air conditioning on the underground because the way the tunnels were specified over a hundred years ago means there is no room for it. Cyclists dice with death on the streets of London because of a consistent design philosophy which gives precedence to cars and in which billions have been invested. We use copper cable to carry data not because it’s a good way of doing it, but because it’s the installed way of doing it – and it takes superhuman efforts to overcome the inertia of the installed base.

We just have to deal with the problems inflicted on us by those who went before us. Is there anything we can do to avoid inflicting similar problems on those who follow us? Probably not, as that’s the same as asking whether we can predict the future but not be caught out by unforeseen discontinuities – it could happen, but it almost certainly won’t. As Charlie Stross puts it

The near-future is comprised of three parts: 90% of it is just like the present, 9% is new but foreseeable developments and innovations, and 1% is utterly bizarre and unexpected.

If hotel room designers had paid more attention to the 9%, it might be easier to plug in all the gadgets. But in a hotel room generation’s time (however long that may be), when there are wall to wall power points, perhaps we will be in a 9% zone where we won’t need any of them any more, or even in a 1% zone where there some means of storing and transmitting power which makes the whole infrastructure utterly redundant.

So what can we do, beyond reminding ourselves yet again of the wisdom of Yogi Berra (or perhaps somebody else) that it’s hard to make predictions, especially about the future? We can attempt to insulate different layers of architecture from each other, to minimise the extent that the faster moving are constrained by the slower moving. We can increase the speed of obsolescence and renewal, trading modernity for hard cash. We can do more to ensure that design thinking reflects the 9% as well as the 90%, though again at a cost, since some of the 9% will never go mainstream. We can choose to give our money to hoteliers with more sockets and better wifi than their competitors.

But in the end, perhaps all we can do is try more explicitly to counter our tendency to get the balance wrong in how we look at the very near and slightly further futures. As Roy Amara, who played a big part in putting thinking about the future onto a more rigorous basis, put it:

We tend to overestimate the effect of a technology in the short run and underestimate the effect in the long run.

Better questions get better answers

Posted by

3

Getting the right answer is important. But it is impossible to get the right answer unless we ask the right question. Time and effort invested in better questions pays off in better answers.

There used to be a zebra crossing across the main road. Pedestrians could get across easily and motorists were discouraged from using the side roads, because they had to wait for a gap in the traffic before being able to turn into the main road. Then the zebra was replaced with traffic lights. Pedestrians have to wait much longer for their turn to cross and it’s much easier to turn out of the side road. More people use the side road as a short cut, accelerating towards the lights to squeeze through on green. So then the side road needed traffic calming measures, with humps and layout changes to slow the traffic down. That hasn’t worked terribly well, so now new and humpier humps are being proposed. But that’s focusing on the wrong part of the problem. Getting rid of the traffic lights would be a far more effective solution.

There is a security door which is opened by a pass card. The card reader is on the same side as the hinge, the door is quite large and opens outwards automatically. If you are standing in the right place to reach the card reader, you are standing in the right place to block the door as it opens. The door opening device has a sensor to stop the door crashing into people. So if it detects somebody in its way as it is opening, it reverses and closes again. It is common to see people dancing around to be able both to open the door and get through it before it decides to close again (their confusion demonstrating a singular lack of affordance). The sensor certainly stops people being hit. But that’s focusing on the wrong part of the problem. Moving the card reader to the opposite wall would be a far more effective solution.

There is an online transaction which because of its overall structure sometimes asks for the same information at different points in the process. That introduces a risk of inconsistency, so there are rules in the system which test whether the same answers are given to the same questions and flags an error if there are any discrepancies. The inconsistency risk is managed effectively. But that’s focusing on the wrong part of the problem. Streamlining the process to ask for each piece of information once would be a far more effective solution.

Once you start looking, it’s surprisingly easy to find problem which exist only because they are the solution to an earlier problem. It’s terrifyingly easy to get trapped in a framing of the question which focuses attention on the immediate symptoms rather than on what caused the symptoms to be generated in the first place.

This shouldn’t be hard. An analysis technique as simple as the five whys would help with each of those examples, but all too often not even that level of structure is applied. Too often we focus on the quality of the answers to questions. Too often we would do better to focus on the quality of the questions we are trying to answer.

Print and be damned

Posted by

0

The private sector, as everybody knows, has clear and customer-friendly systems and services, because the customer is king. The public sector, on the other hand, revels in the obscure and incomprehensible because… well, just because.

And so it was with a light heart that I set out to fix a security flaw in my printer (one of those chores which never existed until Moore’s law came along to free us from drudgery).

The rest of this post sets out the process in mind numbing detail, partly as minor therapy for me, but more importantly because as with several recent posts, telling these stories is a powerful way of bringing to life why service design is not just an affectation and because every one of them is a reminder that we are constantly at risk of inflicting this pain unless we are as constantly vigilant in avoiding it. Fixing printers, opening bank accounts and paying for parking permits don’t on the surface seem to have much in common, but in each case the problem was not that the task could not be completed, it was that there was no sign that anybody involved in designing the service had ever systematically worked through what it would be like to do it as an ordinary user.

The blow by blow account which follows is a fairly grim one, but there is some good news. I went through this process and wrote the account back in January but never quite finished it. Quickly checking the links today shows that the process is now not quite as bad as it was then, with broken links fixed, cumbersome steps made slicker and FTP documents converted into web pages (it also reveals that the printer needs updating again, but lets not worry about that for now).

But that in turn throws up an interesting question about agile approaches. Iterate, then iterate again say the GDS design principles:

The best way to build effective services is to start small and iterate wildly. Release Minimum Viable Products early, test them with real users, move from Alpha to Beta to Launch adding features and refinements based on feedback from real users.

I am with them on that, not least because of the risk they identify in the small print of bottleneck by specification. There is a risk the other way too, though: how good does it have to be to reach the minimum standard? Is anything functional good enough for a first attempt? If we are feeling relatively generous, we can set the bar fairly low for publishing a security alert where there may be real urgency (though it’s not as if this was the first time there had ever been a security alert), but there is a cost. If it was bad enough the first time, it doesn’t matter how good it gets by the second or third time, because I won’t be back to see. Not so much of an issue, perhaps, for an obscure bit of technical support, but critically important in trying to establish a customer relationship.

So the thing which is too often missed in the practice, rather than the rhetoric, of minimum viable products (though not, to be clear, by GDS) is that the minimum is about scope more than it is about quality. That’s not to say that further iterations won’t improve quality; done well of course they will. It is that iteration and user feedback are no substitute for not having done a good enough job in the first place.

And so to the quest through a land of magic and adventure…

Continue reading →

It’s bad to talk

Posted by

1

I phoned a bank today. It was a call I didn’t need to make and which created no value for me. The bank may or may not care about that. It was a call which the bank didn’t need to receive and which cost them money they didn’t need to spend to deal with. The bank really ought to care about that.

The reason for making the call was that the process worked as it should have done from the bank’s point of view. The reason for making the call was that the bank didn’t seem to have realised that working for them wasn’t the same as working for me.

Start with needs* as the GDS design principles have it. The asterisk leads to a snarky footnote, *user needs not government needs. But it isn’t just government which needs to pay attention to that.

This is a story about opening an online bank account. The online bit was fine, but wasn’t enough actually to open the account, because banks legally and prudentially like to know who their customers are, and on the internet nobody knows you’re a dog. So they want to see some pieces of paper. The recommended approach is to take the relevant documents to a branch of the bank where they copy and return them, then send the copies on to their processing centre. Perfectly straightforward, so that’s what I did.

A week passed without hearing from them. Perhaps they are just a bit slow. Two weeks passed without hearing from them. Maybe something has gone wrong. Towards the end of the third week, a letter arrives: they are still waiting for the documents. That’s both irritating and worrying. Irritating to have to repeat the process, worrying that they seem to have lost documents – albeit copies – the whole point of which is that they are sufficient to support a claim to an identity. To say nothing of the fact that losing things is really not what you want a bank to be doing.

And so the phone call. After a little toing and froing I talked to somebody doing his best to be helpful and largely succeeding. There is, it turns out, no record of an account opening application under the reference number I have given, which seems more than a little odd since I have a letter in my hand with that very number on it. But one possible explanation it seems, is that the account has in fact been opened. Would I like him to check? It’ll take a moment, because that’s on a different system. Of course. And it turns out that indeed, the account was opened three days ago, or two days before I got the letter telling me that they were still waiting for the documents.

So from their point of view, everything has been fine: the right things happened in the right sequence through to a successful outcome – at least until I spoiled it by making a pointless phone call.

From my point of view, it’s not fine at all. I spent two weeks not knowing what was going on, followed by two days thinking that the process had failed altogether. A lot of that is down to the long period between their having the documents and their having the knowledge that they had the documents. The letter chasing me for the documents was dated twelve days after they had already been given them (and it took them a further six days to get that letter to me).

Amazon realised a long time ago that the most common question they had to deal with was, where’s my stuff? Overwhelmingly, they deal with that not by being able to tell you, but by making sure you never need to ask. Banks, it seems, still need to learn this lesson.

The more significant lesson though is the one I started with. Process efficiency is in the eye of the beholder. If as a service provider you don’t take the trouble to identify and address the needs of users, the best you can hope for it to meet your own needs as a provider.  And that best is not nearly good enough.

This is not really a story about opening an online bank account. This is a story about how service integration is still rooted in the base as much as in the superstructure. There is still much to do.

Function without form

Posted by

0

image

After two days spent wrestling with the problem of how to distinguish the essential from the desirable from the urgent to ensure that a programme really is focused on driving the highest value first, I realised that a perfect encapsulation of one element of the problem was to be found just down the corridor from the meeting room.

Here is a space to wash your hands. It contains basins, each with taps, soap dispensers and hand dryers. Everything is there to complete the hand washing task successfully. And it all works: there is water in the taps, soap in the dispensers and air in the dryers.

But it all works just a little oddly.

The soap dispenser is automatic: it spits out a froth of soap when you put your hand underneath. The tap works on a plunger: water spurts out when you press the plunger down. It gushes so fiercely and the soap is so frothy that it instantly washes the soap away before it can do anything useful. And then it stops with a disconcerting clanking noise from somewhere round the back, with a delay so short that it took me three bursts of water, even once the soap was under control. The hand dryers are automatic too, sensitive to hands being placed underneath them – so sensitive that they stop if your hands move from a sensor area which seems to be a few millimetres square.

It all works, my hands were clean by the end. The functional requirement had been delivered.

But that’s why functional completeness should never be confused with experience adequacy.

Approaching change (almost) asymptotically

Posted by

0

The skill of a pilot is in bringing vertical speed to zero just at the landing point.

The skill of a bell ringer is in bringing rotational speed to zero just at the balance point.

The skill of managing change is in making the rate of change as close to zero as possible at the point of change.

Successful pilots, bell ringers and change managers do this apparently effortlessly by preparing their trajectory well ahead of time and being continually alert to changes in the environment which might require a correction – but those corrections will tend to be small in relation to the goal.

Unsuccessful pilots and bell ringers crash.

Picture by RTPeat licensed under creative commons

Saying goodbye

Posted by

0

Many years ago, I used to work with somebody who in a previous life had been a restaurant manager. One of the lessons she had taken from that experience was how to say goodbye.

At the beginning of a restaurant meal, people are where they want to be. They are there for an experience, and nobody expects, or even particularly wants, things to happen instantly. Understanding  and ideally matching the customer’s preferred rhythm is part of the service, but there is typically quite a lot of flexibility about exactly how and when different elements of the service are provided.

At the end of a meal, by contrast, people are in a very different mental state. At the point they decide they are ready to leave, any delay or obstacle to their actual leaving is a problem which affects their perception of the entire experience.

The lesson my colleague had taken from that is that there were precisely two steps in the entire experience of having a meal in a restaurant where it was essential to respond immediately to a customer request: when they asked for the bill, and when they were ready to pay it. Everything else had some flexibility, but not that.

In a broader sense, the maturity and self-confidence with which any kind of service provider manages the end of a relationship is one of the most powerful indicators of their overall approach to service quality. Putting effort into helping people to arrive is an obvious and easy thing to focus on (which is not at all to say easy to do well). Putting effort into helping people to leave, and to have faith that that is not only the right thing to do but that it will ultimately help rather than hinder the success of the business is neither obvious nor easy.

Meanwhile, Paul Clarke is ending his ten-year relationship with his mobile phone provider. It didn’t go well.

Blurred reading

Posted by

1

When I was 17, my first proper paid job was in the public library just down the road from the Elephant and Castle. It was the first time I had come across large print books. They had their own section, and there was a huge demand for them. But though it was much more intensely used, the selection was much more limited, partly because they served only a fairly small proportion of the library’s users, but partly of course because only a very narrow range of titles was produced in the first place. They looked very boring and very distinctive – no money was wasted on design or on attracting readers, the covers were just slabs of colour, and they stood out at fifty paces.

That was a long time ago.

A few months ago, I got a kindle, slightly accidentally – I hadn’t thought I wanted one. To my surprise, it has more or less instantly become my preferred means of reading book-length texts. There are several reasons for that, but this post isn’t yet another kindle-groupie breathless review, so I am going to focus on just one feature which, from what I have seen, had got relatively little attention.

You can adjust the size of the text.

The kindle destroys the concept of a large print book, because it’s not the book which has a print size any more, it’s the reader (in both senses, the device and its user).

That instantly means that I can adjust my kindle to a size which is comfortable for me, which is bigger than most publishers’ default, though much smaller than large print. That’s a really useful feature for me as an individual. But it also has much wider implications. It means that there is no reason why every book should not be available for every reader, it means that there is isn’t a highly constrained choice of books for people with weaker sight, and it means that the arbitrary, binary, and stigmatising divide between ordinary books and the large print list goes away.

All of that makes the kindle a lovely example of technology which changes the context in which it operates.

Most of the borrowers of large print books all those years ago were elderly ladies. I doubt that their successors of today are high on the target list for Amazon’s marketing of the kindle. But their successors of tomorrow could find that an almost accidental characteristic of easy technological flexibility brings a segregated service and segregated customers into the mainstream.