CASE STUDY (under construction)
Delivery Updates to Shippers (aka our clients)
Integrating EDI functionality into our portal which already supports email updates
Each Hwy Haul client contract details what specific updates are required and via what channel. The majority of our loads now require updates via a client’s transportation management system (TMS). By integrating electronic data interchange (EDI) into our portal, we reduce friction by eliminating the need to log in 5-10+ times into a client’s TMS for each load we broker for. Generally, this load is fresh produce delivered by refrigerated truck over long distances, 2-5 days.
Perishable food travels by truck, and clients require updates to know where it is.
Role
Interviewing
UX/UI
Walk throughs with users
Tools
Google Meet, Sketch, Zeplin
Deliverables
High fidelity screens for desktop
Medium-fidelity prototype
Timeline
2 weeks
OVERVIEW
The Problem Statement
Our staff is spending more and more time managing the average truck load because more of our clients require updates via their TMS. This problem will ultimately hamper our ability to scale.
Audience
The internal staff that has been sending out updates does not change (but I needed to research who they are and understand their workflow prior to design.)
The Solution
Adapting our existing UI (with email functionality) by adding EDI in a right-hand, contextual panel which is starting to be introduced elsewhere on the portal.
A right-hand panel appears to enable you to send the client updates (shown here without flexing)
My Approach
Given that there was only two weeks before we risked engineers becoming unavailable, I adapted a user-centered design approach whereby I compressed the discovery phase and tried to let Jira define the project scope in order to rapidly develop a prototype for the R&D team to react to. Their input helped me revise the screens that I then showed to the actual users for validation and further adjustments before delivery of final designs.
DISCOVERY
Context and goal
As a third-party logistics company (3PL), we can broker trucking services one load at a time. However, this business relies on relationships which one hopes to translate to ‘committed loads’ which means long-term contracts, volume and generally better margins. That’s how we can scale our business and also navigate an economic downturn successfully. Having recently surpassed 50% of our business being committed loads, we face greater demands in providing our customers the best service possible.
Briefing and video
I met with the head of engineering to discuss this work which he initiated. At the end I requested that he better define the Jira ticket to ensure alignment between me and him, but also with engineering after designs are delivered. I learned that there was a 13 minute video of Yulissa (on the Shipper Sales team) showing how she logs into a TMS to send clients updates. It was helpful to see what the screen flow on a TMS flow looks like. Then, we did another similar session with Aarti from Operations where I got to ask questions.
Combing through our portal and Intranet
I used the QA environment of our portal to understand how email and SMS updates are sent, pressing buttons to see the user flow and what happens.
The existing UI uses a modal with a drop down menu defaulted to Load Status
Piqued by my initial briefing, I sought out our organizational chart to better understand my users who are involved in sending out updates. Then, I dove into our intranet to see the standard operating procedures (SOPs) that the various Operations department ‘pods’ had created for their dedicated clients, looking for similarities and differences.
Key Findings
Users: Individuals from three different departments will be sending updates (HMW help them cooperate?):
Operations does most of the updating since it manages the load en route
Capacity has the closest relationship to the trucks/carriers, so they occasionally find out the status of the load before Operations does
Shipper Sales are ultimately the managers of the client so are involved as needed
TMS types: There are five different TMS platforms being used by our clients. Thankfully, I learned that need not affect our designs since EDI relies on codes that are shared universally: e.g. X6 means ‘driver arrived’.
SOPs: These vary by customer. The updates each asks for often exceeds the 5 updates asked for in this Jira ticket: a loose end to resolve on this project. (HMW help users align with different SOPs?)
History/Time stamp: In the TMS examples I saw, the update ‘event’ was displayed on a table that could have a dozen (!) columns. Meanwhile, on our portal Operations was typing into a ‘Notes’ section in order to (redundantly) capture what was just sent via TMS. Sadly, these client updates in the Notes section comprise only a small fraction of the total notes: a low signal-to-noise ratio which complicates understanding what updates have been sent.
DEFINE
Per Jira
As mentioned, Jira would initially drive the ‘define’ step to save time on our compressed timeline for this project.
The five EDI updates asked for are:
Arrived at Pickup
Departed Pickup
Enroute to Dropoff
Arrived at Dropoff
Current location of driver
I decided to park the ambiguity around the any additional updates required that I discovered in the client SOPs; if I create a framework that is usable, these can be added to as needed, like an item on a list.
The requested updates-sent history needs its level of information detail to be determined; for usability I want to reduce the dozen TMS columns I saw to the bare minimum. With three different departments sending updates asynchronously, I want to locate our history where it would help the team coordinate.
‘Updates sent’ as seen on one client’s TMS
Additional features discussed
A phrase like “It would be great if…” during meetings is either great brainstorming or how scope creep begins. Here are ideas introduced that I considered as I progressed in this project:
“The system should tell you what update is next. It could be a worksheet or function as a to-do list.”"
“The system should tell you when the next update is due.”
“New users should be able to see the customer’s SOP for the load”
“If the trip status (of the load) changes, it should prompt the user to send an EDI.”
“We should have a dashboard where a shipper can see all their loads.”
These items fall into the 'would be nice to have’ department. Or perhaps act as inspiration for solutions during the Develop stage.
DEVELOP
My first order of business was deciding where to locate the entry point for users to start sending an update. I considered four places on a load’s Load Detail screen.
Exploring where to locate the UI and developing ideas where the UI prompts user’s actions (using a red badge and a count)
Option One: uses the existing button and keeps the existing workflow.
Options Two and Four: could put the ‘update’ feature in a logical place with other client related content.
Option Three: would be require introducing a new side bar + icon UI pattern similar to gmail.
Placement: Of the four options I suggested/explored, I leaned toward Option 1 (see above). After conferring with my manager about the options, I felt confident moving in that direction: the teams would benefit by not having to learn a new workflow pattern to update customers.
Selection/Input of Updates: When a user taps the update button, the existing pattern involved a large modal box, and it was defaulted to a ‘delivery status’ update. The obvious solution was to expand the modal’s drop down menu, adding the EDI items to it to contextually change the UI within the modal. Two things I didn’t like about that approach: 1) you can only show one update type as a default in a drop down menu; 2) the very nature of the modal box means that the user is taken out of the context of the ‘load detail page’ when sending an update. Given the fast pace Operations works at — with many interruptions — I felt it would be more immersive and provide better access to information to stay in context. For example, if you were updating the client when their load/truck arrived at a warehouse, it would be easier to be looking at the time rather than having to remember it.
I then pivoted to a pattern I had used for the first time a few months back where a narrow panel appears on the right hand side, and the rest of the content would flex somewhat. I’d have to fit the update options and the update history in this shape.
Update History: My initial questions were:
How many updates would there be per load, minimum and maximum?
Does the data need to match what the client sees in the TMS?;
Can I reorganize it for easiest scannability and the narrow space?
What happens to the existing Notes section?”
I considered using separate tabs for the history and the update options; this would give me the maximum amount of space for each. But I didn’t like having to choose between which would be the default view when the right hand panel appeared. Furthermore, I like the idea of being simultaneously seeing the update history while deciding on what update to send.
I decided to narrow the data for the update history entries from twelve to six fields:
1. update class
2. who sent
3. time of occurrence
4. time sent
5. medium
6. an option for a note.
I chose to work on how to visually configure the six, then have the users react to something (rather than take the time to poll them and synthesize the results prior.) I wanted the system to generate the Update History automatically and decided users can cease typing into the Notes field: time is saved and relevant information is concentrated / easily scanned.
The progression of the Report History: configuring the six data points. The final version makes the ‘time the update was sent’ the most prominent, and it integrates a send/receive status (to the customer TMS) to ensure the feature was working.
First round of feedback
Arrivals and departures I shared my work with the head of engineering (and also a co-founder of the company,) and he objected to my input fields for entering the times for arrivals and departures of trucks: they introduced the potential for a disconnect from the actual data that is collected and manually verified elsewhere via the Trip Status bar which relies mainly on geolocation. An easier and more reliable solution would be to have the system draw that existing data in.
Furthermore, we added a stipulation that if the location data was older than one hour, a verification had to occur before enabling the button. So, this fix would also involve disabling the Send button for these updates and adding error states with an explanation.
Keeping the old UI The right-hand panel would show email options (alongside the EDI ones.) Selecting either of those would then provide another panel to enter the necessary details. The head of engineering made an executive decision to not commit the engineering time to rebuild the secondary panels for email, opting to keep the existing screens. Though it waters down the right-hand panel UI pattern somewhat, at least the users will feel familiar with the workflow.
EDI delivery status Because EDI was acting as an intermediary between our portal and the client’s TMS, our engineering team wanted to monitor whether this method was reliable. I was tasked with creating a UI that could let us know whether 1) the EDI was sent and 2) if the TMS was updated.
Draggable divider Discarding a tabs concept, I had made a decision that my interface should divide the right-hand panel 50/50 between the Update History and the actual sending of Updates. Given that I know some customers have complicated loads involving five pickup and five drop offs, the Update History might get very long. So, I asked whether that 50/50 divider could be made adjustable by the user, and Engineering pleased me by saying yes.
DELIVER
Sharing designs with the actual users After addressing the input received from the head of engineering who initiated this project, we invited users to validate the work; four showed up. I had prepared a medium-fidelity prototype using Sketch to show the general functionality of how the portal would behave. And to account for the various possibilities in the workflow, I tacked variations at the end. The following issues came up to be addressed:
Reorganize the update history making the time when the last update was sent — not the time of the event being reported — the most important datum.
The client’s SOP should be made available. (I’ll place it near the decision point to send updates)
Linking to the Trip Status bar will help users when we disable the Send button for updates. (I’ll embed this link within an error message next to the disabled button in order to empower them. Furthermore, we can avoid this situation earlier in the work flow by prompting the user while the trip status is being verified, then adding a toast confirmation.)
Alerts: I proposed that we could leverage the work I was doing concurrently on Alerts to act as a system prompt for users in the spirit of the to-do-list concept discussed early in the project. This would require our back-end to understand each SOP.
The Trip Status bar feeds times to the EDI update feature but automatically prompts users (after performing a manual time verification) to send a TMS update here, thereby saving time and effort.
Context specific UI The head of engineering and I had a good conversation about leveraging the client SOPs to provide only the EDI options needed for each load, not showing things that didn’t apply to this client. New users would benefit from lower cognitive load.
Revisions and hand off I reconfigured the update history, carefully named all the art boards, added a couple of comments for the engineers and uploaded all the files to Zeplin. The next day I attended the engineering stand up to present the work to the team and discuss any questions they had.
Validation
Given the short time frame of this project, we weren’t able to formally test the impact on this feature prior to staff cuts that included me. Our users said that it currently requires 2-3 minutes to navigate away from our portal to log into the client’s TMS and provide an update . We targeted shortening this to 30 seconds (i.e. an 80% drop,) and based on our conversations with users, felt comfortable about having achieved that by integrating EDI into our portal .
I looked forward to being part of the follow through on these aspects of the project:
Alerts: given the multi-day journeys of trucks, there was research to be done to identify ‘who should be notified and when’ while accounting for different work shifts, departments and absences due to vacation or illness.
SOPs: the intranet guidelines that were created for each client would need to be supported by a user-friendly method to translate the required updates into customized UI options for each load.
This project was a learning experience in moving forward quickly while facing ambiguity on things I wasn’t familiar with such as: parts of the portal I hadn’t understood, the differing/overlapping the roles of the company departments, negotiating with engineering on what was possible to do vs would be actually committed to.
I liked the concept of later developing a dashboard to see all of the client’s truck loads currently in transit, an aggregate view rather than the individual-load level of my solution. The client would likely love to see that, and it would help our company scale up in the future. Nevertheless, the dashboard would still have to work at the Operations level where reps handle many other tasks like confirming warehouse times and receiving gates.