User story: the time travelling courier

User story: the time travelling courier


“I’m really sorry, but it won’t let you sign for another thirty seconds.”

The delivery driver on my doorstep looked apologetically at me, then accusingly at the rugged little plastic computer in his hand. His use of the pronoun ‘it’ spoke volumes about their relationship. When was the last time you referred to your smartphone as ‘it’? These days, for most people, you at least say ‘my’ phone. It suggests you’re on speaking terms and, while you might not always agree, you’re at least willing to acknowledge the existence of a bond between human and machine.

“Oh, right? Well, shall we just wait?” I asked.

“Er, yes, it does this… It’s the timeslot, you see?” He looked down at the screen again, where a timer was running down the seconds.

“Ah, you’re a bit early?”

“Yes. And it won’t let me…” His voice drifted off as he went back to watching the timer.

Sure enough, this judicious delivery driver had made it to the wilds of Norfolk a little ahead of schedule. He works for one of those companies which sends you a helpful email or text the night before to let you know the delivery is coming and then another in the morning advising a one hour timeslot. Unfortunately, his rapid progress through the country lanes had been in vain, because here we were, making small talk in my porch, while technology caught up with real life.

Eventually the screen, running on what may have been some ancient derivative of Windows CE (ask your parents younger readers), refreshed and showed the signature box we’d all been waiting for. I used my fingertip to make the vaguely recognisable squiggle I always do – which we both know no one will ever read – and he handed over the cardboard box.

Now, I quite like small talk and he was a pleasant enough chap, so there were no hard feelings on that account. It was also the first time this has happened. I was more curious than anything else, but it is not hard to imagine this getting old fairly quickly – for both customer and driver.

I’ve thought about the experience a few times over the last few days and wonder what lessons about experience design we might learn from it.

Firstly, what’s actually going on here at a system level?

  • A signature is required to deliver the parcel.
  • The delivery may only be completed during a specified timeslot.
  • If the delivery is attempted outside the timeslot, the signature screen will not show.

The mechanics are basic, even if it had to be torturously coded into some ancient embedded mobile developer kit. The question is why?

  • Is there a security element: that by limiting timeslots to when it is probable the delivery driver would be in the correct geographic location, there is a better chance they’ll deliver it to the intended recipient. Surely that would be more effectively achieved via a geo-fence?
  • Is it about ensuring the driver keeps to their schedule, so that their other timeslots don’t get ahead of themselves?

Whichever way you look at it, the resulting implication for customer experience is upside down. The job to be done is delivering a customer their parcel at a convenient time. Therefore, a system which specifically places barriers between the customer and the efficient delivery of their parcel is antithetical to good user experience.

Furthermore, given how subjectively humans perceive time, a delay at the last possible moment – when the parcel is actually within touching distance – is the worst place it could occur. It doesn’t matter that some truly impressive logistics may have taken place to move an object from around the world to a precise set of geographic co-ordinates within 24 hours. The part the customer will remember is the brief delay on the doorstep, not the efficiency of the invisible integrated transportation network that gets it there in the first place. It’s stupid, but it’s just human nature.

Giles Colborne spoke eloquently and in some detail about these illusions of efficiency and latency at our MEX/14 event. You can watch the video of that session here.

The customer, of course, is not the only user in this scenario. As a delivery driver, I’m guessing you’d find it quite weird to be penalised for completing your deliveries more quickly than expected. It also disintermediates the human worker from the experience. Both driver and customer must simply stand there, awaiting the permission of a digital system over which they have no agency. It makes me wonder what this will look like when the driver is replaced by a drone. Will the robot be able to manage small talk about the weather for a full minute? If I’m going to talk to anyone on my doorstep, I’d rather they at least pretend to care about whether we’re going to get any rain today.

As is often the case, the metrics which we pick to structure and determine the success of digital systems can have unexpected consequences. If anything, perhaps the lesson here is that when thinking about user experience we need to give as much consideration to the consequences of unexpected outperformance as the consequences of unexpected underperformance?

You might want to ponder what the delivery company could have done with the digital or human element of this experience to make that enforced latency a more memorable experience? I can’t help but think there could have been some sort of digital engagement – maybe a screen which allowed me, as the recipient, to see how much ahead of schedule he’d arrived and perhaps hit a little congratulatory confirmation button, that would have created engagement and masked that 30 second gap.

If you have any bright ideas, do please write in.

Part of MEX User Stories, an ongoing series of tales about digital user experience in the real world.

+ There are no comments

Add yours