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.
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
Later, we introduced the ability for users to upload images or videos directly within the flow. This feature came from customer support needs. Describing an issue in text often led to misunderstandings or delays. Allowing users to show the problem visually made it easier to understand the issue upfront, route it to the right vendor, and reduce unnecessary back and forth. This improved accuracy in handling requests and helped shorten repair times and operational effort.
Impact
While exact metrics were not available, the redesigned flow reduced friction across the process.
Supporting multiple actions within a single request removed the need for duplicate submissions and simplified the experience for users. It also made the process more efficient for customer support, reducing repeated handling of similar requests.
The addition of visual uploads improved issue clarity and helped teams route requests more accurately, contributing to faster handling and fewer delays.
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