UX Soup for the Management Soul

UX design translated.

Thursday, January 7, 2016

USPS, your underwear is showing

To kick this off, I'm going to pick on a venerable institution: The United States Postal Service. Trusty old USPS bungles online package tracking and, in the process, demonstrates why user experience depends on the quality of your service itself.


Executive takeaway: It doesn't matter how much your online service looks like it'll deliver what your competitors' do, nor does it matter whether it presented well in boardroom demos. The information on your Web app comes from business processes, and if those business are jacked up, customers will see it.


Here's what happened. I ordered a thing online, and the merchant shipped it USPS. I get a tracking number. Below is a screen shot of the USPS tracking page, taken after I received my stuff, a week later. Looks good, right? Clean, attractive design. No clutter; everything belongs. If you think UX is "look and feel", you're covered. Success! Except, not.


  • None of the entries on that page showed up right when the event actually happened but usually several hours later.
  • The delivery date was pushed back by three days after the package was delivered — way to move the target after you shoot. 
  • I got to follow my package's travels, which was not a good idea, because I could see why it took three more days than the USPS initially estimated. It was not a good reason.

Here's the screen shot, then I'll break it down:


USPS package-tracking screen

First problem, timeliness.

Even though each entry shows an exact time, meaning USPS somehow captured the event, many of them only showed up on the Web hours later.

What happened?

One possible explanation is that packages are scanned in real time, e.g. at the Hayden facility, but somewhere between the employee with the scanner and the Web site's database there is one or more batch jobs. In other words, data piles up somewhere and is let out the gate only at certain intervals. Plausible, and understandable. You've seen it before — you have legacy systems, financial constraints, technical constraints. Someone says we can only do this as a batch job. Unfortunately, your customer doesn't know or care. Your Web site has just made your internal constraints visible. That batch job just cost your business in the currency of credibility.

Why is it important?

I'm annoyed. Are real-time updates an entitlement? No. Does knowing that my package is in Idaho as opposed to, e.g., Indiana change anything to me? No. Those are points that were surely made during the development and design process for USPS's tracking service. I hear them all the time, arguments along the line of "It's not like it makes a big difference to customers!" You could, in fact, insert random data and I'd be none the wiser. (Come to think of it, if the USPS had just made up some data, like "October 28, 2015, 2:42 pm On Truck Cradled By Elves", I would probably have been satisfied provided that entry showed up at 2:42 pm and not half a day later.)


Here's the problem — FedEx and UPS's tracking is real time. Real real time. That's my expectation because someone else has set the bar there. Whether or not it's useful for me to obsessively check the progress of my commemorative Groundhog Day placemats is irrelevant, because with your competitors I can. You don't get to argue with customers that it's not important. (In any event, if real time tracking is not important, why go to the trouble of exposing events and time stamps on the Web in the first place?) So, whenever I buy online and I have a choice, I'm going to choose ... not USPS. If I can choose between two or more sellers, and one offers FedEx while the other offers USPS for the same price, what do I choose? The USPS loses business. That's the bottom line.

Second problem, overpromising and underdelivering.

Through October 30, USPS's tracking page showed "Updated Delivery Day" as October 27.  In other words, not only was it inaccurate to begin with, it was wrong after it became obvious the package couldn't physically make it (from central Missouri to Kansas) in time. Better yet, it kept showing the unrealistic delivery date after the day had come and gone.

What happened?

Speculating again, I'll spin you a little just-so story based on similar experiences I've had elsewhere in the corporate world: USPS doesn't have enough data to make accurate predictions, so everyone involved settled on a "good-enough" algorithm. During discovery, nobody took the time to consider what should happen if the prediction fails or build logic into the system to predict, based on date and location, whether the date is feasible at any given point (e.g. if the expected date is two hours from now and the package is in another state). By the time development has started, changing anything is much more expensive, so it gets put in a "parking lot" or "back burner" for a "future release." Which is the equivalent of the attic — you'll all be so busy catching up with bugs and new feature requests that "back burner" items will never actually be built.

Why is this a problem?

This one is pretty obvious — I'm ticked off because I didn't get my stuff when they said I would, and I'm doubly ticked because the date they gave me appears to have been more or less random. Customers are willing to forgive you when something goes wrong, but it looks from the tracking service as if USPS didn't care enough to make it realistic in the first place. Another reason why I'll choose a vendor who uses FedEx or UPS when I have a choice. Not only does that cost the USPS business, it costs businesses who choose to offer USPS as the only low-cost shipping option.

Third problem, schizo business processes.

According to USPS tracking, the night of October 26, my package went from Kansas City, KS, just a few miles from my house, to Hayden, ID. From there, still according to USPS, it went to Jefferson City, MO. The Hayden, ID, entry, is probably just wrong; the package didn't get flown back to Idaho for no reason. What it did do was travel away from Kansas City, KS, just 20 minutes from the destination address, clear in the wrong direction to Jeff City, MO, two and a half hours east of here. Where it sat for three days. For no reason.

What happened?

USPS evidently does not have the sophisticated routing software that UPS and FedEx use. This kind of math is called a travelling salesman problem. It's solvable, but I'll bet you fifty bucks that USPS is hamstrung by the same problem a lot of older companies have: The matter of routes (or, in your business, some other logistical process) is not just a matter of logic and efficiency but the politics of who gets what route and which facility owns this or that area. Departments, middle managers, and offices squabble over who owns what and whose little empire cannot be touched. Those kinds of problems take enormous and high-level leadership to resolve, and they're far beyond the scope of any Web development project.

Why is this a problem?

Another obvious one. I'm already steamed because we're past the expected delivery date, and USPS tracking adds insult to injury by still showing it expects to deliver my stuff in the past. Because time machines. Then I find out that they took my package from a facility 20 minutes away and shipped it two and half hours due east. There's no explanation, and there is no way you can get a live person to look into, let alone explain, what the hell it's doing there. In other words, the reason I don't have my widget I'm anxiously waiting for is that the shipper has some sort of randomizer applied to its routing.

Learnings

If you get placed at the wheel, or the stakeholders' table, of some project that depends on business processes, do everything you can to state as much, and push it up the chain of command as high as you can. Here's what you say: "The success of this projected $[your number here] Web application depends on accurate and timely data, which is out of scope. A thorough review of the current data shows inefficiencies and errors that the new application would make visible to customers. We recommend streamlining the business process, reducing wasteful steps, and making sure data is passed in real time between system before we spend resources on this application."
If that doesn't get a reaction, at least you've covered your ass.

Ask Per “Pierre” Jørgensen

Q: No comments? What gives?

A: Frankly, I don't have the patience for all the anonymous crap the comment field seems to attract. Since you, dear reader, are neither anonymous nor a purveyor of crap, please use my contact form. I promise to read it, and, if your critique is incisive or your question pertinent, I'll post it (with your permission, of course).