Problem

Our operations team was receiving more than 35,000 shipment updates a week—almost 50% of them from one customer. At the time, these updates were being received through an automated email. Each update took time to read through and decipher what changes were necessary to apply. This was a headache for users and added to the overhead costs for a shipment. I was excited by the opportunity to make such a big difference on these users’ day to day, and ended up leading this project.

Discovery

Given a significant portion came from one source, I decided to hold in-person interviews with members from the team that supported this customer to gain a better understanding of the process. It was here that I learned of the different notifications that they were receiving (see images below for a sample).

At best, the notification indicated old and new values, but failed to do so in a user-friendly way, listing times in UZT. At worst, the notification stated a change was made but didn’t list out any of the changes. In this latter case, the team would have to dig into some secondary tools and compare line by line, contributing to a lot of time wasted.

To help me prioritize which updates to focus on, I partnered with the data science team to identify the most frequently updated values. These three contributed to almost 80% of changes.

As we further dug into the existing processes, we learned about additional complexity, particularly with appointment times. It wasn’t just a matter of applying a change—the change was just the first domino and handful of considerations had to be taken into account. The flowchart below captures the decision making that a user had to consider. This included questions like whether there was a carrier assigned to the shipment, whether the shipment was already in progress, and whether the change had impact on subsequent appointment.

Design

We knew from the start that our solution needed to integrate better with our internal tools, our source of truth for everything shipment related.

Given the range of complexity, captured in the flowchart above, we scoped our initial release down to a solution that aimed to clearly communicate the differences but directed the user to manually apply the changes themselves, akin to a to-do list, in case they had additional insight.

Given 60% of updates were one type of change, I crafted a basic click-through prototype to validate the proposed process.

Note: The manual step served as instrumentation to guide future decisions, and training data to inform automation. In fact, one-click apply and automation would eventually follow in subsequent releases.

With the overall interaction design taking shape, I explored a handful of visual patterns that would best guide users in processing and acting on updates. We launched with something closer to the left side of the spectrum below, as we wanted to get something of value out sooner than later, but followed fast with something closer to the mockups at the right side of the spectrum.

Testing and Launch

As we neared the launch, I hosted a series of pre-launch usability tests and invited stakeholders to observe. During this time I analyzed time on task and total clicks, and assessed comprehension.

With no product or project manager, I led the launch of the feature as well, including the training material and roll out strategy.

Results

In the end our work reduced notifications by 57%, which has translated into 100 hours/week of work time saved.