Transformed Xometry's fragmented returns process into an end-to-end RMA system, enabling customers to self-report issues and Case Managers to resolve them efficiently in one platform.
Role
Lead UX Designer and Researcher
Tools
Figma, FigJam, Dovetail, Otter.ai
Team
1 PM, 2 Software Engineers
Timeline
March 2024 – November 2024
When parts didn't meet specs, Xometry's returns process fell apart. Customers emailed support and waited days without updates. Case Managers triaged through back-and-forth emails while losing track of cases across duplicate Salesforce tickets. Sourcing Specialists manually recreated orders because the system couldn't reopen completed orders. Through research with all stakeholders — customers, internal teams, and manufacturing partners — core friction points were identified and an end-to-end Return Merchandise Authorization (RMA) management system was designed.
The Challenge
The manufacturing industry operates on precision and trust. When custom-manufactured parts don't meet specifications, customers need fast resolutions and clear communication. Xometry's platform had historically facilitated seamless procurement, but when issues arose with delivered parts, the process fell back on manual workflows that created frustration on both sides. Email threads multiplied as customers chased updates, and the lack of visibility into RMA progress created bottlenecks that slowed resolution times.
The Objective
The team set out to uncover specific pain points and redundancies in the RMA process for both customers and operations staff — to deliver a cohesive reporting tool that enables customers to submit concerns directly while giving Case Managers centralized tools to action rework or remake orders efficiently.
The team conducted user interviews with two critical groups: internal Case Management and Sourcing team members who handled RMA requests, and customers who had recently gone through the returns process.
Through shadowing sessions and interviews with Case Managers and Sourcing Specialists, significant operational inefficiencies were uncovered.
Many Touchpoints to Reach Resolution
Some cases must go through several teams before decisioning can occur, leading to delays at each handoff.
Excessive Comms Create Bottlenecks
Back-and-forth email threads between customers, Case Managers, and Sourcing teams slowed resolution and created information loss.
Too Many Cases to Organize
Multiple contacts generate multiple, unrelated Salesforce cases leading to lost or mismanaged cases across the team.
Interviews with customers who had received RMAs in the past six months revealed significant frustration with the returns process.
Long Response & Resolution Times
3–5+ days on average for official resolution despite receiving an initial response within 24 hours.
Low Visibility Into Status
No way to track progress on the RMA outside of waiting for a final resolution email from support.
Downward Sentiment Trends
Many customers reported the resolution wasn't worth waiting for — some opting to rework the part themselves.
These findings pointed to a clear solution: a self-service portal for customers to report issues directly, while giving staff better tools to manage and resolve RMAs. Both paths would share the same underlying data structure to ensure consistency and eliminate manual workarounds slowing everyone down.
Before jumping into design, the technical complexity of introducing RMAs as a new domain event in the platform needed to be understood. An Event Storming workshop was facilitated with the Product Manager and Lead Engineer to collaboratively map out the system's domain events, commands, and workflows.
RMA · Event Storming Workshop
Through this exercise, two critical workflow paths were identified: sourcing RMA parts to the original manufacturer versus sourcing to a new partner. A key technical constraint was also uncovered — the architecture didn't allow reopening completed orders, meaning any rework or remake would require creating entirely new orders.
With domain events mapped, technical workflows were translated into user-facing experiences. A key consideration emerged: while encouraging self-service RMA submissions, the manual staff workflow couldn't be eliminated entirely — Case Managers still needed to create RMAs when customers reached out via email or when Account Executives escalated concerns internally.
Staff User Flow & Lo-fis
Customer User Flow & Lo-fis
A dual-path RMA system was designed and shipped that serves both self-service customers and staff handling escalated cases.
Staff Experience
Case Managers can create RMAs manually from the order details page in the ERP when customers reach out via email or Account Executives escalate concerns internally. The flow mirrors the customer form structure, allowing staff to evaluate issues, determine resolutions (refund, rework, or remake), and create orders with pre-populated details — all without recreating orders across disconnected systems.
Case Manager starts in the Salesforce Case and locates a new case assigned to them
Upon clicking into the RMA case, CM reviews the customer-submitted information including:
CM dispositions the RMA and chooses a resolution:
For Rework or Remake, CM opens the order in the ERP to take action.
a. Rework Flow
b. Remake Flow
Once resolution is actioned, user updates case status:
Final action triggers notification to customer with resolution details and expected timeline
Customer Experience
Customers report quality issues directly from their order details page through a guided form. They select affected line items, specify issue types, upload photos, and receive immediate confirmation with case tracking details. This eliminates back-and-forth emails and gives customers transparency into their RMA status.
User clicks "Report an Issue"
A full page overlays the order summary screen, revealing the first step: "Select Line Items"
Once line items are selected, users are prompted: "Are you reporting an issue to all units of this item?"
a. "Yes" — All units are selected
b. "No" — User inputs the unit count manually
Once all line items/units are accounted for, user clicks "Continue to Provide Issues"
User is prompted: "Do all selected units have the same issue(s)?"
a. "Yes"
Issue menu appears — user selects all applicable issues
b. "No"
Issue groups are created (default 2, expandable), each with its own issue menu
User can submit at this point OR complete optional fields:
a. Upload Attachments
Documentation/photos help Case Managers resolve issues faster
b. Additional Notes
Captures granular details not otherwise surfaced in the form
Final submit triggers a loading state; once the Salesforce case is created, user receives a confirmation screen
47%
Usage
of RMA cases submitted via self-service portal
30%
Efficiency
faster resolution time compared to the old process
86%
Satisfaction
CSAT for the new RMA reporting experience
By collecting complete information upfront through the structured form, back-and-forth triage communication that previously delayed resolutions was eliminated. Customers could submit all necessary details — line items, issue types, photos — in one submission, allowing Case Managers to make faster decisions. The high CSAT score and adoption rate validated that the self-service experience was both intuitive and effective.
