Each supply chain associates are using a least 2 different tools to track POs and search for PO details. So far as we've learned, there are 7 individual visibility tools. The UIs were built a decade ago. Without proper maintenance of the code infrastructure, the performance of these tools are also compromising.

Our goal for the project was to improve the visibility into PO information. Our high level goals are to:
1. Increase the ease of use with clean and intuitive UI
2. Help prioritize tasks for users
3. Provide real-time and accurate data to remove communication frictions

I am leading the design of the One Visibility web application, starting from research to MVP screens.
‍
I am working with 1 product manager, 2 business stakeholders, and an engineer team which has doubled due to the expansion of project scope.
‍
The MVP is currently under UAT phase, and its release is anticipated in late Feb.

I was both surprised and not surprised by the findings. As I somehow expected, handling a list of tools is not a great experience. And besides the visibility tools, they are also using other productivity tools such as big query.

However, the tools are not used for different scenario as I assumed. Instead, users are using them simultaneously in a task. And there are two main problems causing this issue.

When tracking POs, our users are actually trying to answer a series of questions. And sometimes they will need to digging into one PO and learn everything about it.

But since the tools are providing different sets of data, our users often need to turn to a second tool for additional information.  

The data infrastructure of these tools are built very differently, which leads to different refreshing cadence. To get the most accurate shipping information, users have to compare the data between the tools for the most updated one.

Such inconsistency is also causing misalignment between teams. It took extra efforts to validate the data between systems, and clear out the confusions.

So back to the original question: why did we have these many visibility tools?
Here is one possible explanation: the organization structure and operation protocol could have been very different in the old days. So they could be targeting at different user groups for different scenario. There might be a team designated to emergency POs but no longer exists. The business and work flow kept involving, but unfortunately the systems didn't.

The users are focusing on either a department or a location, but the email reports is providing all of the active POs in the supply chain. Then it became an unpleasant experience for filter and sort the table every single time. So some divisions developed a new work flow - the someone at the divisional level creates reports for each of his division merchant managers, and the division merchant managers do the same to their regional managers. Averagely it would cost them half an hour to download, filter, validate, export, and finally send out those reports. What's more, they need to carry out this task three times a day.

Since these reports are manually created, there could be mistakes which lead to back and forth communication. And the situation can be super chaotic when someone is left out the email chain.

The divisional level users who are sending out those reports are either from transportation team, or distribution operation, because they enjoy more visibility into the shipping with their own systems.

Due to the low data quality in the current visibility tool, they were and still are often approached to provide shipping updates. As time passes, they somehow start to shoulder the responsibility of validating and confirming the data from visibility tools, and finally they are assigned to edit and send reports manually. And that's the only reason they are using those visibility tools.

Referring back to the journey map, only two user groups are following the entire PO process. We reviewed the goals and roles of each group again, and defined them as the real end consumer.

The data is the fundamental of a visibility tool. It's critical to answer "what to provide" and "how to provide" at the beginning.

What:
To ensure a smooth all-in-one experience, we need to offer as much as possible, so that our user can enjoy full visibility in one place.

How:
As a data team, the quality of data is our core. By quality it means timeliness and accuracy. We need to identify the best source for pulling each data point. For instance, the transportation system has the most latest update about ETA.

In order to get feedback focusing on the data integrity with less distraction, we validate the data points using an excel sheet instead of a prototype.

For the data quality, the balanced team conducted a series of working sessions, inviting all the data stakeholders as a focus group, running tests on big query. It lasted for three weeks and we identified solid data resources.

After we sent out the excel sheets to stakeholders and users, most of the questions we received was about the source of data. It's interesting that people have concern about the resource so we probed into it. It turns out to be a trust issue. They have little confidence in the data quality and they want to confirm they are seeing the same data as the other teams see.

My product manager and I saw a great opportunity here to win trust from our users and make deeper engagement.

When testing this design, it was interesting to observe that participants were happy to see this piece of information, even though they said its a "good to know".

One of the primary tasks that our end users are carrying out daily, is monitoring what went wrong in their business, and resolve those issues as quickly as possible.

The current practice is filtering and writing formula in the excel sheet. For example, to find an "awaiting shipment" issue, they build an extra column calculating how many days has been passed since the PO created, and then filter down to the ones have blank in "Shipment ID", and finally sort the table to see what's been waiting over three days.

These manual process is more cumbersome when investigating all types of issues. If we can automate the process, it would save our user approximately 15 minutes on processing these excel tables every time.

We gathered a list of exceptions that users would like to identify. In the concept test, users were excited to see exceptions are labelled.

But our users are confused by the grouping of exceptions and the layout. It took them quite a while to understand the table.

It's never easy to overturn a long-established perspective about one thing. In this case, it's the table structure. Our users have been immersed in the excel sheet and out dated UI for so long. They are trained to look at the data in certain way. My product manager and I agreed that we should onboard our users with something they are familiar with and confident about. Elevating experience through design is never a sudden innovation, but long, smooth transition.

After each interview session, we asked our participants We analyzed the sample data provided by our participants, and found each of them are managing their excel sheets very differently. They build tabs by different metrics, and prioritize different columns to front.

One thing I found common in retail practice is that, each of our retail associates develops their own habits and tactic to manage file and documents. In my previous projects, no matter how clean the UI is, some users would still download the excel table, and organize the columns in an order they are comfortable with. What they enjoy is the control and flexibility.

Great question. The request was originally aiming at providing mobile access to users anytime, anywhere. In our user interviews, we also learnt that the merchant managers need to visit the DCs and stores at a regular cadence. It's inconvenient for them to carry a laptops while walking around in the buildings and handling goods and pallets.

But is the right solution by simply squeezing the data table into their phones?

In one supply chain training session I was listening in, associates are talking about operation flow enhancement. And one ask is "stop emailing field people tables. Reading table on a tiny screen is difficult. Try delivering the message in a succinct manner."

So in my exploratory research, I was trying to figure out, if in a succinct manner, what users want to know most.

When the user is visiting the fields, they are doing hands-on work, laser-focusing on the goods in the building. They are running from one place to another, with little time to rest, not to mention monitoring their POs. What they want to know most in that situation, is if his business facing any huge delay issue. If so, what product, how much quantity, impacting which store? These information would be enough for them to react from the field.

So the solution doesn't have to be a mobile view. It can be an email, or a text message. By learning this user goal, the balanced team decided to put down the responsive view, and switched the direction to notification logic. Currently the engineer team is doing research on the methods and implementation.