Case Tracking
--
How might we help our customers to pivot during a pandemic?
The case tracking project began as a response to COVID. In March 2020 as we moved into lockdown, Nulogy began to consider how we might be able to support our customers through the changing supply chain market. People shifted en mass from shopping in store to shopping online, especially through e-commerce stores like Amazon.
Fulfillment centres like Amazon require all incoming cases to be individually labelled with the contents information and a unique Serial Shipment Container Code (SSCC). Our software could be used to generate SSCCs, but it was optimized for pallets rather than cases. Our goal was to learn about fulfillment centre requirements and our users’ current workarounds to find a way to support these kinds of shipments.
Design challenge
Add to the existing shipment flow to allow our customers to easily send their products to fulfillment centres.
Discovering the problem
Going into discovery work we made a small team to gather information to discover the full breadth of the problem, and to help determine the best solution. The team was comprised of myself, our team PM, and one of our developers.
We began with two primary customers who were consistently sending shipments to fulfillment centres. One was using an external system and the other was using a painful workaround in our system. We began by understanding their user flows. Through a series of interviews with each customer, we determined the current user flows, and worked with them to create an ideal user flow that would work for both use cases.
The customer who was using our system was finding it to be particularly painful because there was a mass amount of duplication of effort. In order to generate and document each case into a shipment, they needed to manually enter a record for each case, generate SSCCs, then type in each number. There was large margin for human error, not to mention the hours spent copying information into our system. It was to the point where they needed to hire someone whose job it was to document the data.
It was clear that the customers required more automation. Most of the data was already in our system, as they had created the finished goods using our software. We needed to find a way to bridge the gap and to allow users to create and document the necessary data without leaving our software. The final user flow mapped out a method for the users to turn on a setting in their ship orders that would trigger the system to break down pallets into cases. That way, when the user picked inventory for a shipment, our system would automatically add cases to the shipment in question, and would prompt the user to scan a SSCC barcode rather than requiring manual input. As a result, the action would take less time, and there would be less room for human error.
We wanted to ship an MVP as quickly as possible. Using our ideal workflow, we paired down the new features to determine which planned enhancements were essential to simplifying the existing complex workflow. It was clear that our decision to have myself, the team PM and a developer present through the problem discovery work had been a great decision. The cross-functional collaboration helped us to look at the problem and then the solution from all sides. With the PM as the business advocate, myself as the user advocate, the developer as the tech advocate, we were able to determine the best path forward for an MVP that we could complete in a couple of months.
A bump in the road
Halfway through the development work for the MVP, our PM abruptly left the team. We were left with no product support, with a promise that the company was searching for a replacement to join the team as quickly as possible. In the interim I was the person on the team with the most business context for the product, so I stepped in to help cover the product support to the team on top of my existing design role.
I prioritized the items left to develop so that I could better manage when the designs for each bit of work had to be completed. With the plan in place, I began the work of supporting the development team, answering questions, making product decisions, maintaining communication with the primary customers, and prioritizing the backlog.
The MVP
Our MVP consisted of three main changes: adding the case tracking setting, creating a central place to generate SSCCs and case labels, and allowing users to scan SSCCs as they picked inventory.
Our major issue was making changes to picking. Picking is the formal process by which fork lift operators (FLOs) choose inventory from the warehouse for consumption, or in our case, shipping. Nulogy uses what they call “Mobile” to provide picking and other FLO specific actions. Mobile is not an app or a responsive version of the software, rather it is a paired down version of the software designed for use on a tablet. It was built a long time ago, and very little had been done to add function or even maintain it.
As such, it was extremely difficult to work in.
The UI was outdated and the interactions were suboptimal, but making larger changes were not in scope for the project. I had to learn how things worked in the current state and design something seamless that could work within those parameters. Even more difficult were the technical constraints. Mobile was built in outdated technologies that the developers first had to spend time learning so that they could make change. Each addition to Mobile was difficult and took much longer than we were hoping.
Picking required users to scan a pallet that they were going to use, then to confirm drop off at a specific location in the warehouse. Our enhancements meant that if you had turned on the case tracking setting for a shipment, you would be able to print case labels from the shipment, and then all related picks would require the scanning of the SSCC barcodes on each provided label.
Our system would use existing data to identify the number of cases, and therefore the number of SSCCs that needed to be scanned. Then, when the FLO confirmed the drop off of the pallet, the case information including the SSCC numbers would be automatically added to the shipment.
Once we completed the MVP, we continued work to enhance the flow further.
Displaying case information
As it was, each case was being added individually to the shipment. This made the data very difficult for our users to monitor or review, and it was a huge technical load on our system to generate a shipment with sometimes thousands of individual items.
I worked closely with the customers to create a method of displaying items in a shipment that would be easy to understand and manage. Again, it was not in scope to make major changes to the existing page, rather the design had to work within the parameters of what was already there.
The page had been designed and built long before Nulogy’s design system was created. We decided that the best course of action would be to build what we could using the design system without changing everything. It was a unique challenge to design using the design system in a seamless way in tandem with legacy.
The design explorations into displaying the necessary information came other challenges. We needed to explore how to allow the user to make changes to existing data, and to bypass the automation and to manually enter new data.
We tested a few versions with the users. What resulted was a table similar to the existing table that would group like items together. The SSCCs were quickly overwhelming, so we allowed the user a way to show/hide that data as needed. Users would be able to add, edit, and delete data, but any change to quantity would prompt the scanning or manual input of related SSCCs to ensure the right data was being sent.
Along with this change, we made other tweaks based on user feedback, including streamlining the method of case label downloads, adding safeguards to shipments to avoid sending a shipment with obvious errors or making a change that would result in an error, and researching fulfillment centre guidelines to create a default case label that would satisfy the parameters of most destinations.
In conclusion
From beginning to end, this project took 9 months. Our PM departed in month 3, we released the MVP in month 4, and I was acting PM and designer for the last 6 months of the project. Nulogy tried different methods of providing product support, including having other PMs onboard onto the project on top of the work they were doing for their other teams, and at one point they hired a PM who left a month later.
I have always prided myself on my ability to understand and maintain business objectives, and to collaborate effectively with developers, and this project really solidified that for me. As acting PM, I was responsible not only for the user and for the design, but for final decisions when we would be at a crossroads, understanding the technology and technical constraints so I could advocate (and design) for the project effectively, and to motivate the team to continue when things were difficult.
Ultimately, we created a feature that has pivoted the way that our users connect with their consumers. When we parked the project we had built something that was functional, easy to use, and that provided immense value to our customers.
