When features go wrong

I spent last week in a hotel, where the bathroom lights were on a motion sensor. Walk in, lights on. Leave, and a while later they go off by themselves. On the surface, this seems sensible enough.

Except that every single day, in the middle of my shower, the lights went out and left me standing in darkness, fumbling for the light switch, halfway across the room.

It appears that once I was in the shower, the sensor couldn’t detect me anymore and so it started counting down. Somebody installed that sensor, presumably to cut the building’s electricity bill, and if it had been calibrated properly, I might not even have noticed it was there.

So what actually went wrong?

In the Kano model I described five groupings for product features, and the last of them is Reverse Quality, where adding a feature actually makes the customer less happy. I framed it then around the features we bolt on to justify charging more, the ones that pile up until the product is harder to use than it was before.

That’s real, and it isn’t what happened in the hotel. Nobody was upselling me. The feature was well intentioned, it was cheap, and it was aimed at a genuine problem.

It landed in Reverse Quality anyway, because it didn’t quite work.

Which grouping a feature lands in isn’t a property of the feature. It’s a property of the customer’s experience of it.

A motion sensor that’s tuned correctly is Indifferent Quality at best for the user of the shower. I don’t care that it’s there and I get nothing from it. It is, however, a benefit for the hotel and is likely a performance need from their perspective.

A feature like that has to be nearly flawless to be worth building at all. Anything less and you’re trading a benefit the customer never notices against a failure they’ll tell people about. I’m telling you about it now, which rather makes the point.

You might be thinking that’s a badly installed sensor, not a product decision. Except it’s both, and the product decision came first. Somebody chose to automate something that a light switch already did perfectly well, and that automation only pays off when it’s invisible.

We do this constantly in software. The session timeout that logs you out partway through the form. The autosave that faithfully preserves the version you didn’t want. The notification that’s genuinely useful right up until it fires in the middle of a demo. All installed for good reasons. All of them serving somebody who isn’t the person sitting in front of the screen.

Mostly, the people who build these things never use them the way the customer does. Years ago I sat behind one-way glass watching bank staff use software I’d helped write, and learned that just about all the design assumptions I’d made were wrong. This sensor could have used some real product testing too.