40% OF THE $800B SHIPPING INDUSTRY IS SPENT ON THE LAST MILE OF TRUCKING, and yet TERMINAL-TO-WAREHOUSE logistics ARE STILL being DONE MANUALLY. 

 

TL; DR

In a world where goods from all corners of the world are shipped in lightning-fast speeds, the import industry is lagging far behind with its network of coordinators still tracking, dispatching, and invoicing deliveries using pen and paper.

The San Francisco-based startup Terminal 49 is a SaaS platform which automates the majority of the manual tasks in the drayage process. This last mile of trucking in the journey of a cargo shows huge potential: 15M containers arrive annually on the top five U.S. ports alone. 

Terminal 49 has approached us with the challenge of improving their seed-round product into a more efficient tool: the complexity in drayage involves aggregating tons of information from a number of sources for every single container that arrives on the ports and coordinating the chain of activities leading towards its final destination. 

I have led a team of seven product designers to help Terminal49 with this visibility problem. To calm the maelstrom of data that make up the last mile of trucking, my team sought to refine Terminal 49's dashboard interface.


ROLE: product design lead


Terminal49's staging demo at the start of the project

With shipping giants like Flexport and Knight Trucking's attempt to enter the drayage market amid the operational limitations and archaic methods still being deployed, it is more important than ever to elevate Terminal49 into a digital product that would disrupt traditional norms in trucking. 

 

user focus: the process


Personas, Scenarios and MVP

While the client has already laid some research groundwork for the initial stages of the visibility project in their deck, the initial challenge was to grasp the very concept of drayage before furthering with any design work. Along with informational-gathering interviews with the client, we performed a thorough SWOT and competitive analysis of the industry landscape along with familiarizing ourselves with the staging demo.

Because of the nascent nature of Terminal 49 as a SaaS, the usual practice of coming up with the personas had to be adjusted according to the limitations of the current product. Simply, the client identified five personas who are already Terminal49 clients. My product design team, in turn, found another. We narrowed it down to two distinct key users: J and M, in order to come up with the minimum viable product (MVP) for the duration of the contract.

Even with the nuance of the personas being actual current users, it was necessary to come up with scenarios to further understand the goal of the application.

 
scenarios_01.jpg

Identifying Pain Points

The data overload, less than intuitive interface, and excessive email notifications exacerbate poor user experience — they deter the user from addressing actionable items within the workflow. Basing the organization on the Delivery order,  the same identifier as the Bill of Lading, was too broad and need clarity and specificity. Lastly, the overall visual design was outdated and needed some improvement.

After the research stage, the team then set to formulate several task flows that the personas J and M follow. These visualized the features and components to be used for the following ideation sessions.

 

Wireframes from Design Studio

Wireframes from Design Studio

Design Studio

Eureka moment

After discovering that data can be presented more intuitively according to the four stages of the individual containers along the shipping journey (versus delivery order status as in the demo):

1. On Ship;

2. At Terminal;

3. Picked Up; and

4. Delivered,

we then proceeded to ideation. The four stage structure was key not only for navigation but also as the main component directing the user's actionable items. As Design Lead I have conducted Design Studio sessions with the team to advance towards low-fidelity design with this structure as criteria. 

The exercise yielded two solid directions: a modular/cards system (similar to Google Analytics) and a nested column system (similar to Asana). I have decided to break the team into two groups that would come up two different low fidelity prototypes for A/B testing.

 


Low Fidelity Prototype and User Testing

Version A: cards/modular UI

The first round of testing came with its unique challenges. The low-fidelity prototypes: Version A (cards/modular) and Version B (nested columns) had to be tested one after the other with the same users. Thus, we were careful to formulate the script with the right task flows and questions to avoid inundating the users.

Version B: nested columns UI

It is important to note that the confidential nature of the project limited our user testing to Terminal 49's Operations and Growth personnel — the client wanted to save testing with the actual users until the prototypes were closer to final stage. While their inside know-how is critical, it could also post potential risks in biased results, which are to be addressed later. 

The first user testing and insights gave valuable takeaways that helped the team understand the complex shipping process better. Because of new discoveries, I stumbled upon the need for an unplanned mid-fi prototype combining select features from Versions A and B. This also changed the original MVP.

 

valuable User Insights

  1. High level information counters on both versions of the dashboard not specific enough for user

  2. Collapsible / expandable data fixes information overload, however the "plus" icon is ambiguous; perhaps a "down" arrow is more intuitive

  3. In-app live notifications on both versions are useful and eliminate the need to check numerous emails separately

  4. One of the users tested is dyslexic and could only see the data as "floating"

  5. The nested structure of Version B is intuitive but too steep a learning curve for a non-tech savvy user

  6. Operations can benefit very much from a To-Do list feature so tasks can be checked off

  7. Version A is easier to navigate through with less clicks than Version B

Version A insights

Version B insights


Mid-to High Fidelity Prototype and Validation

Based on user insight, Version A proved to be more intuitive. We took this direction as we advanced into the mid-fi stage. Moving forward, we embarked on the modular route but kept useful features from Version B like color coding and progress bars. Such graphic cues would give the users an enhanced experience closer to the final version of product.

Mid-fi prototype with graphic enhancements

Mid-fi prototype with graphic enhancements

During the impromptu mid-fi design sprint, I have addressed the insights from lo-fi testing to improve existing features and added more that would strengthen visibility and smoothen the work flows. Firstly, the accounts settings became a way for any user to customize information cards to be included on his or her dashboard depending on the actionable items she'd need to address upon logging in. A "flagging" feature was added to mark specific orders (this later turned into "stars" as "red flags" connoted an entirely different meaning to the users). Icon usage was later minimized because they added unnecessary confusion. Instead, buttons proved to be more effective in carrying out actionable tasks. Moreover, we have improved the  global search with the the inclusion of categories to yield more specific results.

Also, even though the client has firmly asked for a global search results page that would show all of the columns related to orders, thereby causing side scrolling, I have respectfully pushed back and solutionized with nested headers and customizable columns in order to avoid any missteps in usability. 

 

 

Design System

I was fortunate to work with a very dedicated group of individuals who each contributed  significant value to the overall product design. As Design Lead I have performed a thorough component audit and built a more solid design system that I and the rest of the team followed as we simultaneously worked on our own sections of the high-fidelity prototype using Abstract. Later, I have included the design system section with the Sketch and Zeplin files as part of the final hand-off to the client.

 
Terminal 49 Design System

Terminal 49 Design System

It was especially gratifying for the team to finally meet the two main (real!) personas during hi-fi testing. J and M’s inputs were extremely valuable as we moved on towards our final deliverables. I have learned that having "real" personas could be uniquely helpful while building a product, for example, J has validated several user journeys the team has hypothesized in the beginning. On the other hand, testing an actual user could potentially make the person feel nervous and perhaps too agreeable when asked for feedback. 

Overall, the validation of the high fidelity prototype with these two actual users, in addition to the three other "real" personas,  yielded satisfactory results. With our usability solutions came increased visibility, less friction and optimized user flow.

 

IMPACT


terminal49_mockup.jpg
 

As of February 2018, critical solutions from our final deliverables will be added in the next iteration of the product and is currently under development. Notably, the four-stage navigation is already implemented in the current staging environment. The other key features that we have come up with, namely: the accounts and notifications settings, customizable columns, progress tickets, and advanced search will also be incorporated into the Terminal 49 platform as the company enters another investment round.