The total customer experience

Last week, I had a delivery from DPD. At one level, it was very mundane (I received and signed for a parcel). At another, it was very positive: I could choose my deliver time to within an hour; I could even elect for a "green" slot when they were going to be in the area anyway (which obviously reduces their cost as well as simplifying my choice). Then on the day I could track the movement of my parcel online and anticipate pretty accurately when it would arrive. The user interface was good, and it was the "front end" of a good system that worked well. This made the overall experience of choosing, ordering and receiving the product much more pleasurable than it might otherwise have been.

In contrast, Samuel Gibbs reports on his experience of using novel Internet of Things tools to do something comparable for frequently bought products. Quite apart from the prospect of having dozens of IoT devices stuck up around the home, he highlights the challenges of receiving the goods once ordered, and of receiving goods in impractically large quantities. These new technologies aren't just about an easy-to-use button-press (like my "easy" button), but about the total customer experience of choosing, ordering and receiving... and someone needs to think that through properly too.

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.

 

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

Mind the gap: the gulfs between idealised and real practice

I've given several talks and written short articles about the gap between idealised and real practice in the use of medical devices. But to date I've blurred the distinctions between concerns from a development perspective and those from a procurement and use perspective.

Developers have to make assumptions about how their devices will be used, and to design and test (and build safety cases, etc.) on that basis. Their obligation (and challenge) is to make the assumptions as accurate as possible for their target market segment. And to make the assumptions as explicit as possible, particularly for subsequent purchasing and use. This is easier said than done: I write as someone who signed an agreement on Tuesday to do a pile of work on our car, most of which was required but part of which was not; how the unnecessary work got onto the job sheet I do not know, but because I'd signed for it, I had to pay for it. Ouch! If I can accidentally sign for a little bit of unnecessary work on the car, how much easier is it for a purchasing officer to sign off for unnecessary features, or slightly inappropriate features, on a medical device? [Rhetorical question.]

Developers have to work for generic market segments, whether those are defined by the technological infrastructure within which the device sits, the contexts and purposes for which the device will be used, the level of training of its users, or all of the above. One device probably can't address all needs, however desirable 'consistency' might be.

In contrast, a device in use has to fit a particular infrastructure, context, purpose, user capability... So there are many knowns where previously there were unknowns. And maybe the device fits well, and maybe it doesn't. And if it doesn't, then something needs to change. Maybe it was the wrong device (and needs to be replaced or modified); maybe it's the infrastructure or context that needs to be changed; maybe the users need to be trained differently / better.

When there are gaps (i.e., when technology doesn't fit properly), people find workarounds. We are so ingenious! Some of the workarounds are mostly positive (such as appropriating a tool to do something it wasn't designed for, but for which it serves perfectly well); some introduce real vulnerabilities into the system (by violating safety features to achieve a short-term goal). When gaps aren't even recognised, we can't even think about them or how to design to bridge them. We need to be alert to the gaps between design and use.

The importance of context (even for recognising family!)

I've been using the face recognition feature in my photograph management software. It was coming up with some suggestions that were pretty impressive (e.g. finding several additional photos that featured my mother, when primed with a few) and some that felt a little spooky (e.g. suggesting that a photo of me was actually of my mother – something that probably none of us wants to admit to, however attractive the parent). But it was also making some inexplicably bizarre suggestions – e.g. that a male colleague might be one of my daughters, or that a wine glass might be a face at all. This recognition technology is getting very sophisticated, but it clearly does not recognise faces in a human-like way!

From a computational perspective, it does not account for context: it identifies and matches features that, in some low-level way, correspond to "face", and it gets that right a lot of the time, identifying real human faces and artificial faces (such as a doll). However, it does not have the background knowledge to do the gender- and age-based reasoning that people naturally do. This makes some of its suggestions seem bizarre. And the fact that it works with low-level features of an image is really exposed when it suggests that a wineglass should be named.

From a human perspective, context also matters in recognition. For most adult faces that were close friends or relations, recognition was generally straightforward, but for children or less familiar people, it was almost impossible to recognise people out of context. The particular software I was using did not allow me to switch easily between detail and context, so there are some faces that are, and will remain, unlabelled, meaning that I won't be able to find them again easily. For example, with context, it was instantly apparent who this small child was: she was sat on her (recognisable) mother's knee, with her big sister at her side. But without that context, she is a small (and slightly uncomfortable-looking) blonde toddler. Context matters.

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!