Wish First Mile Product: Empowering Efficient Logistics Management for B2B product
My Role
UX Designer (collaborating with 1 Product Manager, 1 Product Designer, 2 Software Engineers, in the Wish B2B Product Team)
Timeline
6 Weeks = Research * 2 + Design * 3 + Testing * 1
Tools
Figma, FigJam, Adobe Illustrator
Results
1. Shipped end-to-end UX design and refined the design system with fellow designers for new features of WishPost, Wish’s B2B logistic ERP system handling 1.5 million orders daily.
2. Translated business problems into UX questions through qualitative user research.
3. Designed interactive prototypes from low to high fidelity in Figma for usability testing, and iterated on the solutions based on user feedback.
4. Reduced the waiting time for the first tracking update in system from 4+ days to less than 0.5 day, and achieved efficiency improvement for multiple stakeholders.
Overview
What is the project?
Designed web and app based on optimized workflow to improve efficiency and effectiveness for logistics management in the first mile.
Wish First Mile Solution = [Driver] App + [Admin] Portal
The first mile product is aimed to reduce customer’s waiting time for the first tracking update of orders in the logistics system. It consists of a mobile app for third-party drivers in China, and an admin portal on WishPost ERP for Wish’s logistics administrators to keep track of the orders before they enter the Wish Hubs.
01/ Context
1.1 More about Wish
Wish is an American online e-commerce platform with many China-based merchants. The company plans to start an own first mile management service for business reasons.
1.2 What’s the First Mile?
1.3 The problem
Delayed tracking update in the first mile for 4-16 days.
1.4 My Task in 6 Weeks
How can the new first mile product solve the problem?
Design the MVP
02/ User Research
2.1 The challenge
I need to break down the ambiguous problem into UX questions, and translate the business and user needs into thoughtful solutions.
2.2 Two Direct Stakeholders
2.3 Interviewing logistics admins
We interviewed 2 logistics administrators of WishPost to understand how the first-mile order info used to be updated in the system. Among the China-based merchants, 75% uses carrier service collaborated with Wish to send the packages to Wish Hubs, while 25% takes other approaches because they are not covered by the third party services.
Conclusion:
For the 25%, the new first mile product can include them into the system. The 75% is still providing delayed updates and may need a digital transformation.
2.4 Survey for truck drivers
To recruit first mile truck drivers, I designed an online survey with 4 sections: screening questions, mobile phone/app habits, working process and attitudes toward the industry. Only the participants selected by the first screening section could access the other 3 sections. Among 92 total results, we reached out to 29 drivers who passed the screening section, and 2 of them consented to participate in our in-depth interviews and observations.
Conclusion:
Paper receipts: They refer to the information on various paper receipts.
Digital info: They upload photos of paper receipts/packages somewhere.
Phone activities: Devices, apps, ways of contact, other habits.
2.5 Follow-up Interviews & Participatory Observation
We need to figure out what procedures can be optimized to reduce the delay time of the tracking update in the current working process. We continued to interview the drivers recruited from the survey, and followed them to perform their daily tasks.
Conclusion (Pain Points in User Journey):
Wish: no tracking update (➊)
Admin: too much manual work, hard to trace back (➋)
Driver: time-consuming/error-prone/complicated (➌)
* One driver is responsible for 15-20 merchants, usually with one or more order from each merchant per day.
03/ Translate the challenge into UX questions
HMW design the new first mile tool…
to share the tracking information with all Wish products throughout the first mile,
to save the manual work of logistics admins,
and to reduce time and error for truck drivers in pickup and handover?
What was next?
I presented our research insights to the design team and engineer team for logistics, the marketing team and the CTO of Wish Shanghai. The logistics team in Wish Shanghai decided to start the design and planning of the driver’s app and the admin protal. I was asked to define the main interactions and the design system of the app and the portal in the first stage, to ensure consistent components to the existing design system of WishPost.
04/ Ideation
4.1 Functions
We looked at the existing solutions of both driver’s and admin’s applications to help make design decisions on what features to include in our project.
4.2 Information architecture
We organized the info structure of our app and portal based on the analysis of existing solutions, and further conversations with drivers and admins to confirm the functions included in the first stage.
4.3 Technical decisions: reduce time required to learn + save development time + device compatibility
We discussed our progress with the engineering team for logistics service. We were suggested to design based on the WeChat Mini Program, a WeChat-based framework for quick development. According to what we learned in our research process, an app in WeChat environment means no need to download additional app, easy to share with others, and built-in features to save the developing time including data analysis integration. We also decided to design and test the prototypes with device compatibility in mind, to make sure the users with the oldest version of device were not hindered. We worked with the minimal screen size for responsive design.
4.4 Interactions
The pickup process:
Scan the bar code on the package (manual input for damaged bar codes)
Check the auto receipt
Take and upload photos of packages
Confirm pickup/report problems
Interactions (Mid-fi) - Driver:
Interactions (Mid-fi) - Admin:
05/ Testing & Iterating
5.1 Our metrics
Success rate, percent of functions noticed
Time to complete task, time required to learn, time spent on correcting errors
Satisfaction (1-5)
* Challenge: The participants tended to blame themselves when they failed to perform a certain task.
5.2 Our Approach
For each component we would like to define or edit, we designed 1-3 versions of solutions, and asked our users to participate in the decision making process. We adjusted our design until there was no obstacles for the participants indicated in their feedback on the experience.
One interesting example happened in this stage was that we changed many of the icon buttons to text buttons. Although the components with icon buttons/variants were reported as simpler and more desirable at first by the participants, we found them did not correctly expect what the icons allowed them to do. Instead, short texts turned out to be more friendly to the users in our scenario.
After designing the components with different properties, we added them to the WishPost library of Wish’s design team in Figma.
5.3 Refining component libraries
5.4 Results
06/ Delivery
Driver - Order List
The driver receives pickup orders assigned by admins, auto-sortable by real-time location.
Switch from list view to map view for navigation/pickup planning.
Call the merchants by one left swipe.
Driver - Pickup
Scan the bar code of packages to auto-generate the proof of pickup based on existing info in the WishPost system.
If the bar code is damaged, manually input the code.
Navigate to the hub after the driver finished pickup tasks from all merchants.
Driver - Handover
Scan the QR Code provided by the warehouse for handover, auto-tracked by WishPost.
Change settings including order preferences. View the order history.
Admin - Dashboard
The admin scans the order/driver statistics.
Keep track of the active orders/drivers with map view and table view.
Quickly locate and navigate to deal with ongoing/upcoming tasks or exceptions.
Admin - Active Orders
Batch distribute pending orders to active and available drivers.
Manually create/edit order lists when the order system accidentally fails to auto-update the orders.
Transfer the orders to other drivers when the original availability changes.
Admin - History Orders
Search for completed orders efficiently by filtering time periods, warehouses, drivers and order numbers.
Personalize the number of orders listed per page.
Admin - Driver Management
View and edit all driver info.
Manually import driver info when the system fails to auto-update the driver list.
Track the working process, the proof of pickup, as well as the order receipts shared from the driver app.
Admin - Merchant Management
View and edit all merchant info.
Manually import merchant info when the system fails to auto-update the merchant list.
Edit the regular driver in charge for merchants when driver availability changes.
Takeaways
Breaking down the problem💡
One challenging part of this project was to break down the problem by involving the stakeholders. I explored problems and opportunities for both the company and the end-users, before narrowing down on interactions and design details. When the initial problem was ambiguous, I learned to engage the stakeholders as early as possible in all phases of design. A complex problem can be an opportunity for me to break it down into feasible UX questions and solutions✨
Preventing the Hawthorne Effect💡
Another challenge was to minimize the Hawthorne Effect in design evaluation, and in this case, the participants in testing the prototypes tended to blame themselves when they failed to perform a specific task. That was not really what we want, since there might be frictions in the UX. I also received feedback from the first testing that the participant saw the hi-fi prototypes as something already decided, but not to be refined. After I got advice from senior designers💖, my solution was to provide 2-3 versions for each screen state/component we would like to test. The participants felt more comfortable in this way to click on all the versions and comment on what they expect to see after each interaction. I learned that it's super important to find out what users truly need to produce valid results.
