“Just type the tracking-number into the Google address-bar”, he said. “It’ll take you straight to the Fedex website, without all the hassle of going through the website itself.”

Good advice. And good point, too: always make things easier for the end-user.

So I did just what he said: typed in the tracking number, exactly as it was displayed on the order-form – three sets of four-digit numbers, the sets separated by spaces to make the overall number more readable and usable by humans.

(That’s just a random Fedex number, by the way – not the same as applied in this specific case – but it shows the layout well enough.)

Amazing: Google recognised it straight away as a Fedex tracking number, without my needing to do anything else at all. Impressed.

And yes, it redirected me straight away to the Fedex website, using that tracking-number.

Which is where things went wrong…

“Not a valid tracking-number”, said the error-message.

At which point I started to panic. Well, it was a thousand-dollar item in that now seemingly-untraceable package, so you would probably panic a bit too at that, wouldn’t you?

Just to make it worse, all I had was the tracking-number, with no way that day to contact the Fedex office from which I’d sent the packet in the first place. In short, a day of genuine worry. Ouch…

Finally, though, I had something of a brainwave. I thought about the classic design-errors that arise from organisation-centric rather than customer-centric thinking, and all those user-experience stuff-ups so often caused by lazy programmers thinking only of what’s easiest for them rather than for the person who has to use the end-product of that work.

What would a lazy programmer do, working to a spec created by someone who’d never bothered to look at the real-world workflow or real-world content in that context?

Answer: they’d probably assume that the number is only a number, rather than a string that might contain other characters too. Other characters such as the spaces that are included on the company’s own forms.

Ah, right. So try the tracking-number again, but this time without any of the spaces that are shown in the number’s portrayal on those forms.

Which worked.

Perfectly.

Not just on the Google address-bar, but on the Fedex website too. Straight into a well-structured list of all the places that packet has been so far, including London, Paris, Guangzhou and Singapore, en route to – I hope! – its intended final destination in Australia. Just the kind of detail that we might need when we want to keep track of a rather important and rather expensive parcel.

All of which is all well and good.

Except that, from a user-experience perspective, access to all of that had been blocked by one very small detail. And, for the lack of which, had led this Fedex customer – and how many other Fedex customers, I have to wonder? – into a lot of entirely-unnecessary heartache and more.

In fact, that one small detail was the absence of what was probably just one line of code – a simple RegEx (regular-expression) search-and-replace to strip extraneous non-numeric characters from the string. Something that any experienced programmer would expect to put in there – especially if they know that the content they’re working with has to come in from a web-form of some kind.

Oops…

All of which should remind us, as enterprise-architects and the like, of at least two important points:

Always check the real-world context

and

Even at a whole-enterprise level, sometimes we do have to do a deep-dive down into the details

Doing proper ‘outside-in’ user-experience testing is probably a good idea, too?

Sigh…