Processing Returns
SUMMARY
This project was for Abound (helloabound.com) where I was the founding designer for its two-sided marketplace. Abound is a curated e-commerce platform for buying and selling wholesale.
One of the core benefits that Abound offers retailers is the ability for them to return items that don't sell in their store within 60 days. Returned items get sent to our warehouse and are manually processed by logistics associates who enter the data into a spreadsheet. As Abound grew, it became clear that this process wasn't scalable and we needed to find an alternate solution.
ROLE
Product Designer
TEAM
Product Designer (me)
Project Manager
2 Engineers
THE CHALLENGE
Current Return Processing System Not Scalable
The returns view in Administry (Abound's admin CRM) has very limited capabilities. To save all the necessary returns data, logistics associates would have to manually enter it into a spreadsheet which is not scalable for long-term use as the company grows and the volume of returns grows. Additionally, the spreadsheet makes it difficult to generate reports and analytics to obtain and develop performance insights. And, searching for specific returns in the spreadsheet is tedious and often incurs slow load times due to the rising volume of line items/returns in the files.
The overwhelming and unscalable spreadsheet being used to process all returns
THE SOLUTION
Add Returns Ledger to CRM
Build on the current returns view in Adminstry and design a returns ledger that would give logistics associates the ability to directly enter all the necessary returns data directly into Administry. Allow logistics associates to see a high-level summary of the return and for the return to move through all necessary states.
USER RESEARCH
Clarifying What Capabilities are Needed
To understand what functionalities were needed for the MVP of this feature, I watched our three logistics associates to process a return, asking them to speak out loud while they did so and identify when something was frustrating and felt it could be improved.
Watching a logistics associate process a return
USER STORIES & FLOWS
Seeing it in the Context of the User
Based on the interviews I conducted with the logistics associates, I put together a list of user stories and then worked with the PM and lead engineer on the team to determine scope for the project. I then designed for the highest and medium priority tasks needed to achieve the goal of speed and simplicity when processing a return. Tasks included:
"I want to be able to select/process multiple items at one time"
"I want to be able to see what state the return is in"
"I want to see the name of the Logistics Associate who processed the return"
"I want to be able to see the date the return is processed"
"I want to be able to assign a condition value to each item"
"I want to be able to add notes to each line item"
“I want to be able to see the date the return was delivered”
“I want to be able to add a storage location to each item after return is processed”
THE FINAL PRODUCT
Bringing it All Together
After several iterations where I would prototype a flow, get feedback from the logistics associates, and then update any UI/copy, the designs for the feature were ready. I designed desktop-first because the associates processed returns on a desktop computer.
I made sure to address all of the user stories and account for all possible error states as well.
RESULTS & KEY TAKEAWAYS
How Successful Was the Feature?
The feature was deemed a success:
-
Returns got processed 3x as quickly
-
Logistics associates felt the functionalities defined the scope of problems that could arise with a given product, and the limited and visible options helped them decide which to select and move on.
-
Logistics associates felt it was easier to confirm counts of returned items since you could visually see which products you've already counted and, with the thumbnails, they didn't get lost as easily.
-
Accounting-wise, it removed the need to manually notate which products were of each condition.
