Plugging Holes in the Experience, Sort Of

Back in Holes in The Experience, I talked about what happened if you asked UPS about a package that your e-commerce vendor has readied for shipment, but hasn’t given UPS yet.

Originally, you got a dialog that looked like this:

This looks like an error because that’s how UPS treats it. While the e-commerce vendor has assigned a tracking number, it’s not in the tracking system yet, so it gives a not found error, asserting the user has typed it in wrong. (Interestingly, most of the time, the user hadn’t typed anything—the e-commerce vendor tapped into UPS’s API and automatically generated the error.)

But, UPS has learned. Today, you get this dialog instead:

It’s better, since it doesn’t treat the tracking number like a mistyped error. The UPS system acknowledges that they know a package exists and they even report important details, such as the destination and ship date.

Yet, from the perspective of the e-commerce customer, there’s still a hole in the experience. Stating that the status is “Billing Information Received” still requires the recipient understand UPS’s internal workflow structures. They have to understand that billing information is automatically transmitted through the UPS software that the e-commerce vendor uses to generate the package delivery request. They have to understand that they, the package recipient, isn’t being billed—the e-commerce vendor is.

Anyone want to take a stab at redesigning this to better communicate to the package tracking user what’s really going on?