Shipping label manager application

This assignment tasked my co-developer and I with creating a new shipping label manager application to replace two programs our warehouse staff were using. Our version of the FedEx Ship Manager at the time was not maintained well by FedEx's development team (being in the midst of working on a new application themselves), and the program was powerful but bloated with features that we did not need. We were also using a legacy version of Endicia's application for USPS labels, which had frequent errors. Ultimately neither completely suited our needs, and our users found it frustrating to have to use two different applications to make labels for the respective shipping company.

I was brought on board while the back-end development was already in motion. I conducted user interviews and demos of the current applications to get a feel for what our users needed the application to do for them, and how best to transition their workflow from the existing applications to a new all-in-one program.

I consolidated my findings into a series of flowcharts using XMind and presented the results to the development team. We were able to use it to document the scope of the project, defining must haves and nice-to-haves. It greatly aided my work in developing the information architecture of the application, and helped the team get on the same page on what we were building.

As handy as a flowchart is, most end users get a better sense of an interface from an image. Creating a simple prototype in Adobe XD enabled us to present our ideas before starting development. While not as powerful as other tools like Axure, Adobe XD enabled me to at least simulate user interactions, like how the screen would change when the user clicked the main navigation or show pop-ups that would appear if certain buttons were clicked.

During this process, we discovered important features that we missed during our initial user interviews. For instance, our warehouse staff might “close” a shipping service multiple times a day, and not just once like I had assumed. The development team had to think about showing data for multiple close times (number of packages at each time stamp) and plan for additional actions.

Even with the best laid plans, nothing in development is perfect. We had a unique situation arise after launch with “pending labels.” Initially, if labels came in after a specific time the program would push them to the next business day so the warehouse workers could focus on the orders that had to go out that day. However, on rare occasions a label may be sent to the pending queue but the shipment would need to go out that day (perhaps the customer called and the warehouse staff chose to expedite the shipment). We updated the auto order printer screen so staff could access the pending labels and print them manually if needed.

The biggest lesson learned from this project was how important project planning and user testing is. We have a small team of in-house users to collaborate with so we tend to develop and design on the fly. Fortunately we're in a position where it's realistic to work this way (we can rapidly deploy bug and quality-of-life fixes as soon as the users alert us to a problem or difficulty). That said, we can always strive to do better for the next project.

Defining project goals and having useful documentation are essential to development. Often our developers work alone, so it's natural to approach a project in a more cerebral way (nothing written down, containing all the details in one's head). In teams, however, this makes it harder to onboard new team members, and I had to regather information that had been collected in project requirement meetings months prior. Documentation is a useful resource for tracking project progress, setting and meeting deadlines, and keeping track of changes and decision making.

Showing the users a prototype that was essentially a few animated mockups and emulated interactions was a good start, but ultimately it's still better to have user testing that actually tests task completion. With data entry there are a lot of pieces and odd scenarios that we missed when our testers just passively looked at a series of images. We would have gained a lot of insight if we had a tool that could simulate the interface and let users actually tab through it and enter data. Perhaps we could explore products like Axure, or I could have whipped up a quick web version that would have been a near identical experience.