Designing the Customs App
Too long didn’t read
After envisioning the OS for Customs We set forth into building the first major milestone for Flexport customs, a dedicated workflow.
UX, UI, Strategy, Research, Prototyper
Flexport’s mission is to solve the user experience of global trade. On my product team our goal is to decouple headcount with market growth via automation which reduces our cost-to-serve clients. My work is focused on power users, and providing the best UX for our customs team. It’s information dense, and a business critical area.
Customs is the most deep and edge-case critical vertical at Flexport. It poses the greatest compliance risk to Flexport, and is the most profitable revenue generator for the business. We must file customs documents accurately and on-time to avoid penalties, and provide the best customer experience. The focus of our team’s work is on internal power users, our customs brokers.
Capturing the Flexport Customs Workflow
“It’s not a logical straight through process. So you almost are tricking core to perform with what you want to happen in netchb… if brokers aren’t careful…you’ve created an incorrect entry” - Flexport broker"
High level broker filing workflow
The goal was to understand the requirements for breaking away from our monolithic catch-all app we call core.
Lots of documents need to be viewed alongside the data. So the broker opens the PDFs, and excel sheets in one window and compares it against the data we have in our system. In some cases the data was entered into our system from the documents via our data ops users. Lots of double checking, and double work.
Current state of affairs and issues
There are a lot of issues with the existing workflow.
Lack of dedicated real estate. - Work in the shipment view bloats it with features that brokers don’t need which forces them into a little corner of core.
Increased cognitive load. - Management of windows for each shipment means a broker is constantly fighting to maintain their workspace for each shipment
The software is not helpful, it’s just inputs - There are fields, they need checking and entering. There’s no automated assistance, that could easily be automated.
Trust issues with the source of data
“I want to check legs for dates and ports and tags are correct and transportation mode.”
Double checking work
“I check Manifest query to match number. I double check Manufactuer code to make sure it’s correct.”
Data isn’t correct
“One of the main issues with MIDs with how core does it, is that it formulates it but there’s no guarantee that it’s that address.”
Make the data trustworthy
Go upstream to change data entry points to improve quality.
Show the source of data.
If data needs checking, make it easy.
Removes the burden of managing windows for docs.
Can we check for them to verify it doesn’t need checking?
If data isn’t correct call it out.
The UI should flag whenever the system knows data is wrong.
Requirements from research
Screenshot of the spreadsheet I worked on for defining requirements for this new experience.
High level data components
Data checking overlaps for documents. For example the AN (Arrival Notice) has the most data overlaps with other documents.
After defining requirements these became the high level data components we needed to work with for the broker workflow.
Documents - A dedicated document viewer
Doc Nav - A navigation for moving between documents
Header Info - the header info is all the data tied to the shipment that has to be filed with customs
Invoice Summary - The invoice summary is the set of data attached to the products and commercial invoice.
Ideation and components
There were two main directions to explore for improving the workflow.
Workflow in Steps - Verifying of data in multiple steps with the advantage of reducing information density, and potential cognitive overload.
All in One - All work at the fingertips of the user, allowing for flexibility, but increasing information density.
Ideation on Components
This navigator would allow for quick swapping between documents to verify data.
One idea that seemed great in concept was to use “hover” to trigger a switch to the document rather than having to click. Users liked this, but upon later implementation the reloading of docs slowed the experience.
The header info section contains the data that needs to be verified by brokers. Not all info needs verification all the time, but it provides important context.
This early version shows the source of where we got the data from this is because broker’s habitually question where the data comes from which results in more checking work.
Header: Inline Editing
To discourage editing information we were going to move forward on inline editing. Each data edit is critical and needs to be intentional so we added a save/cancel button.
Header: Smart Fields (Ideation)
The idea for “Smart fields” was born from users distrust of data and a step forward in automation.
“Where is the info coming from? Such as manifest quantity? How did it draw that number when the numbers are incorrect?” - Customs Broker
If a smart field checks data for a broker then
1. They don’t need to check thus saving work time
2. The system can direct the eye to work that does need to be done
3. With points 1 and 2 we improve our goal of improving accuracy and operating efficiency
Prototyping and usability testing
Early clickable prototypes
The first prototypes tested different directions for workflow breaking it into steps or providing a all-in-on experience.
Brokers preferred an all-in-one because it was more flexible to their differing workflows per shipment.
The highlighting of data was really helpful in directing their eye to work to be done.
The smart fields were a hit in not having to check and also know what data to look at.
more interactions prototype
“That’s cool, it points out different information, and fields to look for on each document. I like it, its kinda like a little guide, it helps you along the way. It’s good to see the sources of all your info.” - Customs Broker
The highlights feature was a compelling enough concept from the prototyping to include in the final design spec. Highlighting data related to a doc was helpful in guiding the eye to data that we wanted checked. Smart fields were also helpful in reassuring the user that they didn’t have to check the data, though that will take them time to get used to it.
The reaction from the business was ecstatic, we were making progress towards a future specialist experience. This project later was given additional support to demonstrate that we could create dedicated specialist experiences over generalist ones.
User interviews defined the requirements for this project which gave a greater sense of user empathy for workflow. I setup a vision for direction and tested with paper prototypes into high fidelity interactions that defined the nuances of the product.
While still not feature complete to match broker’s work to be done. Future projects chipped away at getting to feature parity of the old workflow, and improving it where we could.