If the user can’t use it, it doesn’t work: focusing on buying and selling

"If the user can’t use it, it doesn’t work": This phrase, from Susan Dray, was originally addressed at system developers. It presupposes good understanding of who the intended users are and what their capabilities are. But the same applies in sales and procurement.

In hospital (and similar) contexts, this means that procurement processes need to take account of who the intended users of any new technology are. E.g., who are the intended users of new, wireless integrated glucometers or of new infusion pumps that need to have drug libraries installed, maintained... and also be used during routine clinical care? What training will they need? How will the new devices fit into (or disrupt) their workflow? Etc. If any of the intended users can’t use it then the technology doesn’t work.

I have just encountered an analogous situation with some friends. These friends are managing multiple clinical conditions (including Alzheimer’s, depression, the after-effects of a mini-stroke, and type II diabetes) but are nevertheless living life to the full and coping admirably. But recently they were sold a sophisticated “Agility 3” alarm system, comprising a box on the wall with multiple buttons and alerts, a wearable “personal attack alarm”, and two handheld controllers (as well as PIR sensors, a smoke alarm and more). They were persuaded that this would address all their personal safety and home security needs. I don’t know whether the salesperson referred directly or obliquely to any potential physical vulnerability. But actually their main vulnerability was that they no longer have the mental capacity to assess the claims of the salesperson, let alone the capacity to use any technology that is more sophisticated than an on/off switch. If the user can’t use it, it doesn’t work. By this definition, this alarm system doesn’t work. Caveat emptor, but selling a product that is meant to protect people when the net effect is to further expose their vulnerability is crass miss-selling. How ironic!

Making time for mindfulness

You can't just design a new technology and assume people will use it. The app stores are littered with apps that are used once, or not at all. It's important to understand how people fit technologies into their lives (and how the design of the technology affects how it's used). We choose to use apps (or to be open to responding to them) in ways that depend on time and place. For example, on the train in the morning, lots of commuters seem to be accessing news via apps: it's a good opportunity to catch up with what's happening in the world, and my journey's an appropriate length of time to do that in.

We've recently published a paper on how people make time for mindfulness practices.
Participants were mostly young, urban professionals (so possibly not representative of a more general population!), and their big challenge was how to fit meditation practices in their busy lives. Mindfulness is difficult to achieve on a commute, for example, so people need to explicitly make time for it, in a place that feels right. There was a tension between making it part of a routine (and something that "has to be done" and making it feel like a choice (spontaneous?). But there were lots of other factors that shape when, how and whether people used the mindfulness app, such as their sense of self-efficacy (how much they feel in control of their lives), their mood (mindfulness when your upset or angry just isn't going to happen – not in ten minutes, anyway), and attitudes of friends to mindfulness (peer pressure is very powerful).

Some of these are factors that can't be designed for – beyond recognising that a mindfulness app isn't going to work for all people, or in all situations. Others can, perhaps, be designed for: such as managing people's expectations of what differences mindfulness might make in their lives, and giving guidance on when and how to fit in app use. What are some of the take-homes?

• that incidental details (like the visual appearance or the sound of someone's voice) matter;
• that people are one a 'journey' of learning how to practice mindfulness (don't force an expert to start at the beginning just because they haven't used this particular app before, for example);
• that people need to learn how to fit app use and mindfulness into their lives, and expectations need to be managed; and
• that engaging with the app isn't the same as engaging with mindfulness... but the one can be a great support for the other in the right circumstances.

 

Innovation for innovation's sake?

As Director of the UCL Institute of Digital Health, my job is to envision the future. The future is fueled by innovation and vision. And there's plenty of that around. But the reality is much more challenging: as summarised in a recent blog post, most people aren't that interested in engaging with their health data (the ones who are most likely to be tracking their data are young, fit and wealthy), and most clinicians are struggling to even do their basic (reactive) jobs, without having much chance to think about the preventative (proactive) steps they might be taking to help people manage their health.

Why might this be? Innovation is creative and fun. It's also essential (without it, we'd still be wallowing around in the primordial soup). But there's a tendency for innovation to assume a world that is simpler than the real world: people who are engaged and compliant and have time to take up the innovation. Innovation tends not to engage with the inconvenient truths of real life, or to tackle the difficult and complex challenges that get in the way of simple visions.

We need a new approach to innovation: one that takes the really difficult challenges seriously, that accepts that the rate of progress may be slow, that recognises that it's much harder to change people and cultural practices than it is to change technology, but that these all need to be aligned for innovation to really work.

We need innovation that works with and for people. And we need to recognise that an important part of innovation is dealing with the inconvenient and difficult problems that seem to beset healthcare delivery, in all its forms.

Designing: the details and the big picture

I was at a meeting this week discussing developments to the NHS Choices site. This site is an amazing resource, and the developers want to make it better, more user-centred. But it is huge, and has huge ambitions: to address a wide variety of health-related needs, and to be accessible by all.

But of course. we are not all the same: we have different levels of knowledge, different values, needs, and ways of engaging with our own health. Some love to measure and track performance (food intake, weight, blood pressure, exercise, sleep, mood: with wearable devices, the possibilities are growing all the time). Others prefer to just get on with life and react if necessary.

We don't all choose to consume news in the same way (we read different papers, track news through the internet, TV or radio, or maybe not at all); similarly, we don't all want health information in the same form or "voice". And it is almost impossible to consider all the nuanced details of the design of a site that is intended to address the health needs of "everyone" while also maintaining a consistent "big picture". Indeed, if one imagines considering every detail, the task would become overwhelmingly large. So some "good enough" decisions have to be made.

I am very struck by the contrast between this, as an example of interaction design where there is little resource available to look at details, and the course that my daughter is doing at the moment, which has included a focus on typographical design. In the course, they are reviewing fine details of the composition and layout of every character. Typography is a more mature discipline than interaction design, and arguably more tractable (it's about the graphics and the reading and the emotional response). I hope that one day interaction design will achieve this maturity, and that it will be possible to have the kind of mature discourse about both the big picture and the details of users, usability and fitness for purpose.

Three steps to developing a successful app

This comment is based on studies of healthcare apps, and some recent conversations I've had, but I'm guessing it applies more widely:

1. Consider what the 'added value' of the app is intended to be. 'Because it's the 21st century' and 'Because everyone uses apps' are not added value. What are the benefits to the user of doing something with an app rather than either doing it some other way or not doing it at all? Make sure there is clear added value.
2. Consider how people will fit app use into their lives. Is it meant to be used when a particular trigger event happens (e.g., the user is planning to go for a run, or isn't feeling well today), or regularly (after every meal, first thing every morning, or whatever)? How will people remember to use the app when intended? Make sure the app fits people's lives and that any reminders or messages it delivers are timely.
3. What will people's motivations for using the app be? Are there immediate intrinsic rewards or longer term benefits? Will these be apparent to users? Does there need to be an extrinsic reward, such as competing against others or gaining 'points' of some kind, or might this be counter-productive? Are there de-motivators (such as poor usability)? Make sure the app taps in to people's motivations and doesn't put obstacles in the way of people realising the envisaged rewards.

A fourth important point is to recognise that every person is different: different lifestyle, different motivations, different on many other dimensions. So there almost certainly isn't a "one size fits all" app that everyone will love and engage with. But good and appropriate design will work for at least some people.

Looking for the keys under the lamp post? Are we addressing the right problems?

Recently, I received an impassioned email from a colleague: "you want to improve the usability of the bloody bloody infusion pump I am connected to? give it castors and a centre of gravity so I can take it to the toilet and to get a cup of coffee with ease". Along with photos to illustrate the point.

He's completely right: these are (or should be) important design considerations. People still want to live their lives and have independence as far as possible, and that's surely in the interests of staff as well as patients and their visitors.

In this particular case, better design solutions have been proposed and developed. But I've never seen one of these in use. I've seen plenty of other improvised solutions such as the bed-bound patient being wheeled from one ward to another with a nurse walking alongside holding up the bag of fluid while the pump is balanced on the bed with the patient.

Why don't hospitals invest in better solutions? I don't know. Presumably because the problem is invisible to the people who make purchasing decisions, because staff and patients are accustomed to making do with the available equipment, and because better equipment costs more but has minimal direct effect on patient outcomes.

An implication of the original message is that in CHI+MED we're addressing the wrong problem: that in doing research on interaction design we're missing the in-your-face problem that the IV pole is so poorly designed. That we're like the drunk looking for the keys under the lamp post because that's where the light is, when in fact the keys got dropped somewhere else. Others who claim that the main problem in patient safety is infection control are making the same point: we're focusing our attention in the wrong place.

I wish there were only one problem to solve – one key to be found, under the lamp post or elsewhere. But that's not the case. In fact, in healthcare there are so many lost keys that they can be sought and found all over the place. Excuse me while I go and look for some more...

Collaborative sensemaking under uncertainty: clinicians and patients

I've been discussing a couple of 'conceptual change' projects with clinicians, both of them in topic areas (pain management and contraception) where the clinical details aren't necessarily well understood, even by most clinicians. I have been struck by a few points that seem to me to be important when considering the design of new technologies to support people in managing their health:

1. Different people have different basic conceptual structures onto which they 'hang' their understanding. The most obvious differences are between health professionals (who have received formal training in the subject) and lay people (who have not), but there are also many individual differences. In the education literature, particularly building on the work of Vygotsky, we find ideas of the 'Zone of Proximal Development' and of 'scaffolding'. The key point is that people build on their existing understanding, and ideas that are too far from that understanding, or are expressed in unfamiliar terms, cannot be assimilated. In the sensemaking literature, Klein discusses this in terms of 'frames', while Pirolli, Card and Russell discuss the process of making sense of new information in terms of how people look for and integrate new information with existing understanding guided by the knowledge gaps of which they are aware. In all of these literatures, and others, it's clear that any individual starts from their current understanding and builds on it, and that significant conceptual change (throwing out existing ideas and effectively starting again from scratch) is difficult. This makes it particularly challenging to design new technologies that support sensemaking because it's necessary to understand where someone is starting from in order to design systems that support changing understanding.
2. One of the important roles of clinicians is to help people to make sense of their own health. In the usual consultation, this is a negotiative process, in which common ground is achieved – e.g., by the clinician having a repertoire of ways of assessing the patient's current understanding and building on it. The clinician's skills in this context are not well understood, as a far as I'm aware.
3. For many patients, the most important understanding is 'what to do about it': it's not to get the depth of understanding that the clinician has, but to know how to manage their condition and to make appropriately informed decisions. Designing systems to support people in obtaining different depths and types of understanding is an exciting challenge.
4. Health conditions can be understood at many different levels of abstraction (from basic chemistry and biology through to high-level causal relations), and we seem to employ metaphors and analogies to understand complex processes. Inevitably, these have great value, but also break down when pushed too far. There's probably great potential in exploring the use of different metaphors and explanations to support people in managing their health.
5. As people are being expected to take more responsibility for their own health, there's a greater onus on clinicians to support patients' understanding. Clinicians may have particular understanding that they want to get across to patients, but it needs to be communicated in different ways for different people. And we need to find ways of managing the uncertainty that still surrounds much understanding of health (e.g. risks and side-effects).

All these points make it essential to consider Human Factors in the design of technologies to support conceptual change, behavioural change and decision making in healthcare, so that we can close the gap between clinicians' and patients' understanding in ways that work well for both.

Know your user: it's hard to imagine being older

I've just been reading Penelope Lively's enchanting article "So this is old age". It's an engaging read – at least for someone who sometimes thinks that they are experiencing old age! I love some of her description: for example, "the puzzling thing in old age is to find yourself as the culmination of all [your younger selves], knowing that they are you, but that you are also now this someone else". She is very articulate, and presents something like a persona for an older person. She also reminds us that it's easier for the older person to imagine what it's like to be younger than the reverse.

And yet, the older person who she portrays is importantly different from any individual (over the age of, let's say, 75) that I personally know. It is much easier to assume that we all age similarly – that people get more similar as they get older – than to get your head around all the individual differences. But as far as I can tell the converse is actually the case: variability increases as different kinds of degeneration compete against different enhanced competencies (kinds of wisdom, perceptions, appreciations).

We all have a tendency to stereotype "the other", whether they are older or younger, male or female, a nurse, teacher, cleaner or astronaut. It's much easier to design for people "like me" than to put yourself in someone else's shoes and design for them. Personas have an important role in helping to design for others, but they need to be used with sensitivity to real people. That's surely the best design: designing for people who are different from oneself in ways that empower and delight them.

Affordance: the case of door closing

Last week, I was at (yet another) hotel. In the Ladies' (and presumably also the Gents'), the doors had door-plates on the inside, which facilitated pushing but not pulling. Within HCI, this is often referred to as the object affording a particular action. See, for example, work by Gaver and Hartson. In fact this example goes further than affording: it determines what is physically possible. In the case of doors, the assumption is that on one side you expect to pull and on the other you expect to push.

The problem was that in this case the door hinge was very simple: the door did not automatically close. So the only way to close the cubicle door was to pull on the small handle that was designed as a lock (that afforded turning but not pulling). The assumption behind having a plate on one side and a handle on the other is that there is a default position for the door, which could have been achieved if the "system" (aka the hinge) was set up to automatically close the door. But it didn't. In this case, the user has to both pull and push the door to get it to the desired positions -- and yes, privacy is valued by most of us in this situation, so most do want to be able to close the door as well as open it!

I've previously commented that we seem to be unable to design interactive devices as simple as taps; it seems that this extends even to doors... and I don't think interactions get much simpler than this.

When context really matters: entertainment, safety ... or neither?

Yesterday, Mark Handley drew my attention to a video of the recent evacuation of an All Nippon Airways Boeing 787 due to a battery problem: "Here's a video from inside the plane:  The inflight entertainment system has clearly just rebooted, and about half the screens are displaying the message "Please Wait" in large comforting letters. Maybe not the most appropriate message when you want people to evacuate quickly!"

Fortunately, it seems that passengers ignored the message asking them to wait, and did indeed evacuate instead. But did they do so as quickly as they might have done otherwise? We'll never know. They will have had many other sources of information available at the time, of which the most powerful were probably other people's behaviour and the appearance of the evacuation slides. The digital and physical contexts were providing different cues to action.

Brad Karp observed that : "Presumably when you activate the slides, you either want to kill the entertainment system or have it display "EVACUATE!"

Alan Cooper, in "The inmates are running the asylum", discusses many examples of interaction design. One he explores is the challenge of designing good in-flight entertainment systems. For example, he points out that the computer scientist's tendency to deal with only three numbers (0, 1, infinity) is inappropriate when choosing a maximum number of films to make available on a flight, and that choosing a reasonable (finite) number makes possible attractive interaction options that don't scale well to infinity. He also argues that the entertainment system needs two different interfaces: one for the passenger and a different one for the crew who need to manage it. But if you watch the video, you will see that half the screens on the plane are showing a reboot sequence. Who designed this as an interface for passengers? If the system developers don't even think to replace a basic reboot sequence by something more engaging or informative, what chance of them thinking about the bigger picture of how the entertainment system might be situated within, and interact with, the broader avionics system?

In-flight entertainment systems don't seem to be considered as part of the safety system of the aircraft. Surely, they should be. But that requires a broader "systems" perspective when designing, to give passengers more contextually relevant information that situates the digital more appropriately within the physical context.

Happy (entertaining, safe) flying!

It was a dark and stormy night... accounting for the physical when designing the digital

Yesterday, I used the London cycle hire scheme for the first time. I had checked all the instructions on how to hire a bike online before heading off to the nearest cycle station, all prepared with my cycle helmet and my payment card. For various reasons, it was dark and drizzling by the time I got there. The cycle station display was well illuminated, so I could go through the early stages of the transaction without difficulty, but then it came to inserting the payment card. Ah. No illumination. No nearby streetlight to improve visibility. I found myself feeling all over the front of the machine to locate the slot… which turned out to be angled upwards rather than being horizontal like most payment card slots. I eventually managed to orient the card correctly in the dark and get it into the reader.

Several steps of interaction later, the display informed me that the transaction had been successful, and that my cycle release code was being printed. Nothing happened. Apparently, the machine had run out of paper. Without paper, there is no release code, and so no way of actually getting a cycle from the racks.

To cut a long story short, it took over 30 minutes, and inserting my payment card into four different cycle station machines distributed around Bloomsbury, before I finally got a printed release code and could take a bicycle for a spin. By then it was too late to embark on the planned errand, but at least I got a cycle ride in the rain...

The developers have clearly thought through the design well in many ways. But subtleties of the ways the physical and the digital work together have been overlooked. Why is there no illumination (whether from street lighting or built into the cycle station) for the payment card slot or the printout slot? Why is there apparently no mechanism for the machine to detect that it is out of paper before the aspiring cyclist starts the interaction? Or to display the release code on-screen to make the system more resilient to paper failure? Such nuanced aspects of the situated use of the technology in practice (in the dark and the rain) have clearly been overlooked. It should be a universal design heuristic: if you have a technology that may be used outdoors, check that it all works when it's cold, dark and damp. Especially in cold, dark damp cities.

If we can't even design taps...

Today, I got a wet arm: the tap control was immediately behind the faucet, so I reached through the line of fire to turn it on, and the inevitable happened. But it looks Well Designed:

I thought I had already encountered every possible type of poor design: the tap that is unpredictable because there is only one control to govern both temperature and flow rate:

The tap that needs the explicit notice to tell the user how to make it work:

The taps where it's almost impossible to tell whether the water will flow from the shower head or the main tap:

The tap that looks as if you should turn it, when actually that controls the temperature, not the flow; for that, you have to pull the control towards you:

Yvonne Rogers told me of a tap that would only work if you were not wearing black....

The user of a tap wants to control two parameters: the temperature and the flow rate. There are plenty of designs around that enable people to do this without any faff at all. But these are apparently not interesting or exciting or aesthetically pleasing enough. So innocent users get frozen, scalded, bemused or unexpectedly wet as tap designers devise ever more innovative taps. If we can't even get tap design right, what hope for more complex interactive technologies, I ask myself...

 

An accident: lots of factors, no blame

At one level, this is a story that has been told many times already, and yet this particular rendering of it is haunting me. I don't know all the details (and never will), so parts of the following are speculation, but the story is my best understanding of what happened, and it highlights some of the challenges in trying to make sense of human error and system design.

The air ambulance made a tricky descent. Although the incident took place near a local hospital, the casualty was badly injured and needed specialist treatment, so was flown to a major trauma centre. Hopefully, he will live.

What happened? The man fell, probably about 10 metres, as he was being lowered from the top of a climbing wall. It seems that he had put his climbing harness on backwards and tied the rope on to a gear loop (which is not designed to hold much weight) rather than tying it in correctly (through the waist loop and leg loop, which were behind him). Apparently, as he let the rope take his weight to be lowered off from the climb, the gear loop gave way.

I can only guess that both the climber and his partner were new to climbing, since apparently neither of them knew how to put the harness on correctly, and also that there was no-one else on the wall at the time (since climbers generally look out for each other and point out unsafe practices). But so many things must have aligned for the accident to happen: both climbers must have signed a declaration that they were experienced and recognised the risks; the harness in question had a gear loop at the centre of the back that they could mistake for a rope attachment point... but that loop wasn't strong enough to take the climber's weight; someone had supplied that harness to the climber without either providing clear instructions on how to put it on or checking that he knew...

So many factors: the climber and his partner apparently believed they were more expert than they actually were; the harness supplier (whether that was a vendor or a friend) didn't check that the climber knew how to use the equipment; there weren't other more expert climbers around to notice the error; the design of the harness had a usability vulnerability (a central loop that actually wasn't rated for a high load and could be mistaken for a rope attachment point); the wall's policy allowed people to self-certify as experienced without checking. Was anyone to blame? Surely not: this wasn't "an accident waiting to happen". But the system clearly wasn't as resilient as it might have been because when all these factors lined up, a young man had to be airlifted to hospital. I wish him well, and hope he makes a full recovery.

The wall has learnt from the incident and changed its admissions policy; hopefully, there will be other learning from it too to further reduce the likelihood of any similar incident occurring in the future. Safety is improved through learning, not through blaming.

Designing for "me"

The best designers seem to design for themselves. I just love my latest Rab jacket. I know Rab's not a woman, but he's a climber and he understands what climbers need. Most climbing equipment has been designed by climbers; in fact, I can't imagine how you would design good climbing gear without really understanding what climbers do and what they need. Designers need a dual skill set: to be great designers, and to really understand the context for which they are designing.

Shift your attention to interaction design. Bill Moggridge is recognised as a great designer, and he argues powerfully for the importance of intuition and design skill in designing good products. BUT he draws on examples where people could be designing for themselves. Designers who are also game-players can invoke intuition to design good games, for example. But judging by the design of most washing machine controls, few designers of these systems actually do the laundry! There seems to be a huge gulf between contexts where the designer is also a user, or has an intimate knowledge of the context of use, and contexts where the designer is an outsider.

It's often easy to make assumptions about other people's work, and about the nuances of their activities. You get over-simplifications that result in inappropriate design decisions. Techniques such as Contextual Inquiry are intended to help the design team understand the context of use in depth. But it's not always possible for the entire design team to immerse themselves in the context of use. Then you need some surrogates, such as rich descriptions that help the design team to imagine being there. Dourish presents a compelling argument against ethnographers having to present implications for design: he argues that it should be enough to provide a rich description of the context of use. His argument is much more sophisticated than the one I'm presenting here. Which is simply that it's impossible to reliably design for a situation you don't understand deeply. And for that, you need ways for people to become "dual experts" – in design, and in the situations for which they are designing.

When is a user like a lemon?

Discussing the design lifecycle with one of my PhD students, I found myself referring back to Don Norman's book on emotional design – in particular, to the cover picture of a Philippe Starck lemon squeezer. The evaluation criteria for a lemon squeezer are, I would guess, that it can be used to squeeze lemons (for which it probably needs to be tested with some lemons), that it can be washed, that it will not corrode or break quickly, and that (in this case, at least) it looks beautiful.

These evaluation criteria can be addressed relatively rapidly during the design lifecycle. You don't need to suspend the design process for a significant length of time to go and find a representative sample of lemons on which to test a prototype squeezer. You don't need to plan a complex lemon-squeezing study with a carefully devised set of lemon-squeezing tasks. There's just one main task for the squeezer to perform, and the variability in lemons is mercifully low.

In contrast, most interactive computer systems support a plethora of tasks, and are intended for use by a wide variety of people, so requirements gathering and user testing have to be planned as separate activities in the design of interactive systems. Yet even in the 21st century, this doesn't seem to be fully recognised. As we found in a study a few years ago, agile software development processes don't typically build in time for substantive user engagement (other than by involving a few user representatives in the development team). And when you come to the standards and regulations for medical devices, they barely differentiate between latex gloves and glucometers or interactive devices in intensive care. Users of interactive systems are apparently regarded as being as uniform and controllable as lemons: define what they should do, and they will do it. In our dreams! (Or maybe our nightmares...)