RMA
Design System
For: R2Net (James Allen & Blue Nile)
Return Merchandise Authorization handles how customers return, resize, or repair their jewelry across Blue Nile and James Allen.
RMA
Design System
Multi-brand
E-commerce
Overview
RMA (Return Merchandise Authorization) is the system that handles what happens after the purchase, when customers need to return, resize, or repair their jewelry.
This is also a moment users never really plan for. Something went wrong. The size is off, the product arrived damaged, or it simply did not meet expectations. By the time they reach this flow, they are already frustrated. Because of that, the goal was to make the experience as clear and effortless as possible, helping users complete their task quickly and move on, while supporting a system that works seamlessly across different brand identities.
The Problem
The original RMA flow was built as a linear process. Users had to choose a single action first, resize, repair, or return, and then complete the flow step by step for one item at a time.
In reality, this did not match how people behaved. Customers often needed to handle multiple items within the same order. Someone resizing an engagement ring would likely need to resize the wedding band as well. But the system forced them to open separate requests for each action, creating a repetitive and frustrating experience for both users and customer support. Even simple scenarios required unnecessary effort, and the flow did not scale well as complexity increased.
Behind the scenes the process was just as heavy. Every return involved an agent calling the customer, because return reasons were not saved in the system and a refund could not be issued without one. Each action could also generate its own prepaid shipping label, so the company often paid for up to three labels on a single order.
Understanding the problem
The project was driven by product and operational needs, but reviewing the flow made a key gap clear.
The system forced users into a single-action process, while real scenarios often involved multiple items and actions. This mismatch led to repeated steps, unnecessary navigation, and a break in the user's flow.
Designing a more flexible RMA experience
I redesigned the flow to better reflect real usage, moving from a rigid, linear process to a more flexible system.
Instead of forcing users to choose one action upfront, I introduced a side panel that allows them to handle actions per item, while keeping the main context visible. This made it possible to resize, repair, or return multiple items within the same flow without restarting the process.
The side panel also solved a key usability issue. In the original flow, users had to scroll down to complete an action and then back up to select another item. This broke the sense of progress and made the experience feel disjointed. Keeping the interaction in a focused panel allowed users to move forward without losing their place.
This shift required restructuring the logic from order-level to item-level, allowing each product to carry its own action and details while keeping the overall experience clear and manageable.
Designing for multiple brands
The RMA flow had to work for both Blue Nile and James Allen, two brands with different visual languages. For a long time, we maintained two separate design-system files, one for each brand, which meant duplicate patterns, drift, and extra work whenever the flow changed.
To support one experience that could run cross-brand, we consolidated into a single master file that houses both DSMs in one place: a shared, variable-driven system where the same components and tokens can switch for Blue Nile vs James Allen instead of living in parallel files.
That unification let us design and ship one RMA flow that behaves consistently while still respecting each brand's look (for example, rounder vs sharper surfaces) without maintaining two divergent sources of truth, especially in a functional, system-heavy flow.
It also cut inconsistencies and gave us a clearer base for future work on shared product surfaces.
Improving issue clarity with visual input
Clarity starts with the reason itself. As part of the project we rebuilt the list of return, resize, and repair reasons based on years of accumulated cases, and the selected reason is what determines how each request is handled and where it goes. An additional remarks field lets customers describe anything the list doesn't cover in their own words.
On top of that, we introduced photo and video upload. Describing a damaged or ill-fitting item in text often led to misunderstandings and delays; showing it removes the guesswork. The uploads sync to every system involved, customer service, the merchandise team, and the vendor's own system, so a vendor can see the issue and prepare before the package even arrives.
Impact
Repairs & resizes come back in 2 weeks
Turnaround used to be six weeks, and most of that was logistics, not the repair. The coarse reason list meant a repair sometimes went to a vendor who didn't specialize in that problem and had to be rerouted. With structured intake, the piece goes to the right place the first time.
One request, one box, a whole order handled.
Returning, resizing, and repairing items from the same order used to mean starting three separate flows from scratch. Now the customer handles everything in one request and ships it all back in one box. Agents see the whole order in one place instead of three scattered requests, and the company pays for one prepaid label instead of three.
Every request now teaches us something.
We rebuilt the reason list around years of real cases, so when a product keeps coming back for the same reason, the merchandise team can trace it to a vendor quality issue. An additional remarks field gives a fuller view of the problem, in the customer's own words.
One system now serves both brands.
Blue Nile and James Allen used to be maintained as two separate design-system files, so every change had to be built twice, and the two kept drifting apart. One variable-driven system means one RMA flow shipped once and maintained by one team, saving R&D hours on both new features and upkeep. It also leaves the door open to more Signet brands joining later.
One upload, every team in the loop.
Instead of describing a damaged item in words, customers show it. The photo syncs to customer service, the merchandise team, and the vendor's own system, so a vendor told that all the pave stones fell out sees the picture and can prepare before the package even arrives.
No phone call needed, nothing lost in an inbox.
Every return used to involve an agent calling the customer, even when the customer opened the request themselves, because the reason had to be entered by hand before a refund could go out. Now it's fully self-serve, everything is stored in the system, and the records are finally consistent enough to track and learn from.
Final thoughts
This project reinforced how important it is to design beyond a single flow and think in systems.
By shifting from a linear experience to a more flexible structure, it became possible to support real user behavior without adding complexity. Small structural changes had a large impact on both usability and operational efficiency.
It also highlighted the value of aligning design decisions with real constraints, balancing flexibility, clarity, and scalability across both the user experience and the system behind it.
Next project