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.1 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 problemselective 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’.2 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.3

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

  1. This wasn’t the more familiar message that there is no cash which tends to come much earlier in the process, it came right at the end after the point when there is normally any point in looking at the screen at all.
  2. I have never read that as meaning that nothing should ever change and nobody should ever innovate, but as reminding us that expectations are formed by experience which is much wider than a single site at a single time.
  3. This is of course all a conscious retrospective rationalisation of an unconscious reaction at the time –  which makes it prone to error as an account of what I thought, never mind what the site did.

Comments

  1. Hi Stefan
    Thanks for this suitably thought-provoking post. I’m one of the Patient Opinion team, and I wanted to respond to that part of your post specifically.
    First, to apologise. It is an incredibly frustrating experience to write a post which then disappears, and I’m really sorry. (I’m also sorry we don’t now have it on our site, since I know it would be very worthwhile feedback.)
    Second, to say that two or three users have also reported this experience in the past 6 months, which has prompted us to try to prevent it. We didn’t find an obvious cause, so pending further investigation, we added the note which, as you suggest, is probably inadequate.
    And finally, to thank you for the blog analogy. I agree – you would expect the post to sit and wait indefinitely until you are ready to click [Next]. We should re-engineer this bit of the site to allow this, and we’ll take a look at this next week.
    Apologies again for a poor user experience.
    James Munro, Patient Opinion
    PS: I wrote this elsewhere, just in case ;)

  2. An interesting and thought provoking article.

    Here’s an example closer to government. The online Universal Credit application has an gateway section which checks whether a claimant is the right kind of person to make a claim in the pathfinder phase. There are twenty five questions, distributed over five pages. The application effectively disables the browser’s back button, but that doesn’t matter very much as it provides its own navigation buttons: it’s easy to move between pages.

    When a claimant who is eligible for universal credit successfully answers these questions they are invited to make a claim. Sensibly, the application shows the claimant a summary of the information he or she has entered, requesting confirmation before commencing the claim proper.

    But suppose a claimant who *is* eligible for universal credit makes a mistake answering one of these gateway questions. They are simply told that they are ineligible and advised to claim JSA or look for other benefits. There is no summary of the information entered, and, crucially, no reason is given for their ineligibility. And there are no navigation buttons. If they do try to use the browser’s back button, they will be asked if they really want to leave the page, though there is, quite literally, no benefit to be had by remaining on it. If they do leave the page, they are (somewhat cryptically) invited to resend the form, though doing so has no useful effect. Persist long enough and the application puts up a message saying that the service is temporarily unavailable. (This page, at least, does put up numbers for the helpline).

    The sole recourse is to restart the application from scratch. Only users with a strong prior belief in their entitlement will be likely to do so.

    PS: I have painfully trained myself to compose all blog comments etc. into a text editor before posting, though it’s usually my urge to fact check that has led me astray rather than any fault in the software.

Comments are closed.