Modes of failure

A lot of care goes into designing successful interactions. The same level of care is needed in the design of unsuccessful ones. Three times in the last three days I have been wrongfooted by interaction failure, from which I draw three lessons.

The three examples are very different from each other in some ways, but in each case the failure emerged, unexpected and unheralded, from apparent success, so creating confusion as well as disappointment.

The first was one of the simplest transactions we all do without thinking about it – getting cash from a machine. All went swimmingly: card in, pin in, amount in, card out – but no money. The machine clearly thought the transaction was over and was all ready for the next one. But I had no money, and no idea whether the machine thought I had or not. While I was dithering, the next person in line was brave or foolhardy enough to venture her card. Her experience was exactly the same – except that now we were looking for it, we spotted a fleeting message at the end that the machine wasn’t actually in a position to dispense cash.¹ Much relief all round, but a brief moment of consternation which should have been avoidable.

The next morning I was in Pret a Manger, paying by contactless bank card. The process couldn’t be simpler: there is one green light on the terminal when it is ready and a row of four or five when the connection has been successfully made – when you see that, you are done. Except that I was told the payment hadn’t gone through and that I needed to do it again. Now a payment of £1.25 is hardly a matter of life and death, but I was curious – it had all looked fine to me. The till was apparently capable of printing a chit showing the amount due, but not one which showed the state of the transaction. Neither of us, it seemed, could be completely clear what had happened. The short term effect was that I got a (possibly) free pretzel, but that’s not a terribly satisfactory way of resolving things. Below the line of brightly shining affirmatory green lights on the terminal, there is a little lcd screen, showing dark grey letters against a marginally less dark grey background. It’s possible that something appeared there that I entirely failed to notice, but once I had seen the green lights, I wasn’t looking for anything else.

And finally, and much more subtly, I was writing a story that evening to go on Patient Opinion. I wrote, I reflected a bit, I wrote a bit more. When I had finished I clicked the ‘next step’ button – and everything vanished. Then – and only then – did the significance of some innocuous-sounding instructions sink in. The words were simple enough:

How long will this take?

About five minutes. You’ll enter your story, which area you live in, and add some tags to make your story easy to find.

If your story will take you more than 10 minutes to write, save it elsewhere. Then return here, and paste your story into our form.

With the benefit of hindsight, I take it that the process runs on some kind of session basis and that I had timed out – I had certainly taken more than ten minutes over it. Unlike the other two examples, in principle the message was in the right place and I had noticed it at what should have been the right time. But that didn’t actually help, partly because I didn’t start with the intention of taking a particular amount of time (and I certainly wasn’t keeping track of the minutes as I wrote), and partly because there is no indication of what the effect of taking longer might be. It might even be that there is an anchoring effect from setting an expectation at five minutes which makes it less likely that people will stop to think whether they are actually likely to take longer.

I take three lessons for interaction design from those three examples.

Don’t give people critical information when they can’t be expected to be looking for it

The more familiar the interaction, the less we will pay any real attention to it. If it is working the way we expect it to, that’s fine. If it’s very obviously not working the way we expect it to, that’s also fine. But if it looks as though it’s working the way we expect it to, but isn’t, that’s a big problem – selective attention may prevent the difference from being noticed at all. The worst possible time to tell somebody something is when they think you have already finished telling them things. The second worst is before they know enough to recognise the significance of what you are telling them. The point at which a ten minute warning might be useful on Patient Opinion is after 9½ minutes, not while the input field is enticingly blank.

If you need to break people’s expectation of what is happening, do it explicitly, preferably to the sound of trumpets

The corollary of the first lesson is pretty obvious. If something is happening in a way the user may not be expecting, make that obvious and break the flow. In the Pret example that might mean making the lights flash red instead of green, at a cash machine it might mean requiring an acknowledgement of the message – or perhaps better still, making sure that the message is still on screen at the point the penny drops that the expected event hasn’t happened and the user is actively looking for an explanation.

Try to understand other peoples’ analogies

It’s getting on for fifteen years since the law of internet user experience was framed, but I don’t think it is less true now that ‘users prefer your site to work the same way as all the other sites they already know’.² I would though add the corollary that users expect your thing to work in line with the mental model they have of it, so it really matters to understand what that model might be. Having understood it, we can either support it or help people understand that their model doesn’t quite fit.

My past experience tells me that some kinds of interactions are session based and time out, while others are stateless and don’t. The more directly transactional an interaction, the less I will be surprised that it won’t be there if I come back later – booking tickets being the obvious example, and shopping baskets generally not far behind. At the other extreme, I can leave a half written blog post in an open tab for days or weeks and expect it still to be there when I come back. Telling a story on Patient Opinion feels much more like blogging to me than it does booking a flight – and so a set of assumptions was triggered which turned out to be wrong.³

But above all those lessons, there is a simple principle: design for what goes wrong, as well as what goes right.

Original post