To give some background on ShipHawk’s platform, its software uses an algorithm called Smart Packing that’s intended to give merchants the most ideal packing configurations.
However, Smart Packing isn’t always accurate, especially for users that are shipping oddly shaped items. This is where TeachMode comes in.
TeachMode is a way for users to manually override the configurations given by Smart Packing and to “teach” the software what the actual configurations should be.
So when workers pack that same combinations of items in the future, they can keep reusing these configurations.
I started off by familiarizing myself with the shipping industry and then the ShipHawk site. Through observing user journey video clips from FullStory and discussions with Product Team members, I took time to understand how a warehouse worker processes a shipment with the default algorithm vs. TeachMode.
Since TeachMode was a relatively new feature, there weren’t too many FullStory sessions I could analyze for user issues. I relied on existing design principles and made sure to include my design manager and PM in the design process. Having someone to bounce my ideas off not only allowed me to refine my designs, but it also helped me articulate my design decisions better. Overall, the teamwork translated well into the designs.
Upon going through the flow of TeachMode, the “Save as Packing Rule” modal stood out to me as the page that was most disruptive in the user experience. These were the 3 specific areas that I decided to focus on improving for the redesign.
At first glance, the lines of text and lack of visual hierarchy made it difficult to scan and quickly process the information. With this being a summary page, users want to be able to quickly ensure that the information they’ve inputted is correct and move on to the next order. This can be especially difficult when there’s a bunch of packages to scroll through.
Information that the user had manually inputted was not consistent on this summary page. There was unnecessary information as well as missing data such as SKU quantity and names.
KITs are items that belong to a single SKU. The current designs do not currently support KITs, which are necessary for customers that ship them.
After deciding on what aspects of the page to improve on, I worked on different iterations. These iterations were presented for feedback with the PM, who brought up various use cases and feedback that helped inform the next iteration.
During my initial meetings with the PM, we were able to talk through different cases that the design would need to account for in order to address different user needs. One of these cases was for customers shipping Parcel vs. customers shipping LTL. Both contain nearly the same information but unlike Parcel, LTL has more levels in shipment hierarchy. Thus, the summary modals would look different based on if the order was Parcel or LTL. It was a challenge to brainstorm ways of displaying different levels of information, while also trying to keep both the Parcel and LTL versions as consistent as possible with each other.
Wording - “Collapse” -> “Collapse all SKUs” for clarity
Added flexibility - Addition of Show/Hide SKUs button on package level
Easier reference - Moved Shipment weight and Total packages to sticky part of modal
Once I was able to finalize a high fidelity prototype with the PM, I then documented the frames for the developers to explain design details and microinteractions. We communicated frequently through Slack, where they would send any questions about certain design details and functionalities and I’d provide clarity. I was also able to test out the page on the QA site and commented any edits and areas of improvement on the Redmine ticket.
Verify new packing configurations
Scan quickly through different parcels or handling units
Save as a packing rule for future use.
I was very fortunate to be on a team with individuals that have supported my growth throughout not just this project, but my internship. Shipping is a complex industry, which reflected in the ShipHawk site, and so this project was a challenge from the get go.
Having collaborated closely with a PM and Developers over the course of this project, I got to explore different ways of communicating my designs with my teammates. I found myself gravitating towards certain methods of communication depending on the individual I was working with. With PMs, the iteration process was more efficient when I was communicating earlier and more frequently. Meanwhile, for Developers, annotating my prototypes aided greatly in translating designs.
This project was my first experience designing for a B2B company and for a new industry. Unlike my previous design experiences for B2C, SH has a lot more complex user flows, user personas based on tasks, and different roles such as Sales and Implementation Engineers involved with the project. This was a new and fun challenge for me as a designer crafting a user experience in unfamiliar territory.
Still in its early stages, TeachMode as a feature was enabled for 3 of our customers, whom I was able to review through watching FullStory. Through these user sessions, I was able to check if there were any glaring usability issues, and intend to continue getting user feedback in future feedback and discovery calls.
As this feature continues being enabled for more customers, some of the success metrics we aim to look out for include:
Increased # of Packing Rules created
Reduced time spent checking Packing Rule before vs. after redesign