Building an application to help Relief factor manage returns!

Rebuilding a tool to help a homeopathic medicine company manage package returns

Project Overview

Challenge

There was an overload in returns being shipped, and each one needed to be manually scanned and handled, which became very inefficient and time consuming.

Objective

Design a user flow that requires as little deviation as possible; Basically, allow the user to get through as much volume in the shortest amount of time.

Key Takeaways

Throughout this project, I spent a lot of time prioritizing user flows, and given the linear structure of this application, was able to learn a lot of "best practices" when it comes to structuring multiple flows in an app. We successfully delivered a design that the team and the clients were super happy with, and it also gave me the opportunity to work with other designers and delegate tasks as a full project lead

Project Scope

Redesign a return manger application with new functionality

My Role

UX Designer in charge for research, visual and interactive design, user testing, as well as the primary UI Designer in charge of designing an intuitive design

Tools used

- Figma - Adobe Photoshop

Team Input

Me and one other designer worked together with Relief Factor to come up with a design we were happy with

Duration of Project

2 months

1. Research

Key Takeaways

In the research phase, we were reviewing all the documentation that was provided to us, which was very useful, since it actually provided us with a user flow based on actual user data collected from the app prior to us joining the project. Through this, we gained a better understanding of how the package return process currently operated, and how a package was categorized immediately upon arriving in the fulfilment center, as the package could arrive in many different conditions, labeled in many different ways. In order to address this, we conducted our research.

Research Plan

Understand user needs, goals, preferences, etc
Made a list of assumptions to confirm or rebut, as it gave us a baseline understanding of what needed to change

Preliminary Research

Conducted user research and ask the staff at the fulfilment center directly, and get a demo on how each package is returned
Categorize the different states a package could arrive in, and how these could affect the flow

Details

Qualitative Research

The initial research involved understanding the market and navigating platforms like Amazon. This groundwork was vital for framing questions in the primary research phase. The focus then shifted to Relief Factor and their returns team, as the app was intended for internal use rather than wide-scale consumer deployment. Interviews with the project lead, agents, and a warehouse manager provided diverse insights into the layout and logistics, including warehouse operations, package processing, and the condition of returned items.

Package Condition

The project's key aspect was the package condition for returns. Relief Factor's (RF) policy requires products to be returned in factory-sealed packaging with "Refused" written on it. However, variations occur when customers return packages without marking them or in different conditions. At the RF facility, the team first checks for "Refused" and then assesses the package's state: whether it's opened, the condition, and if it's in a factory or customer box. These varying scenarios influenced the return process, leading to the creation of specific flow names for each condition.

"Unopened Factory Refused" This is the fastest return procedure, as we have all the information we need; A working barcode/order ID to identify the customer, in a still still sealed package, meaning there is no need to verify the contents.
"Unopened Factory Not Refused" This is ALMOST the same as the unopened factory refused, but since the package is opened, you need to verify the contents inside to make sure everything is present.
"Opened Factory " This is where we begin straying to the complicated scenarios. Given that it doesn't say refused, we can't know for sure if the customer wants a refund, or if something else potentially happened, such as an invalid address or something. As such, more info needs to be provided here.
"Customer Package" If the factor package isn't present at all, meaning there is no way to identify the customer via barcode/order ID, then we have to search the customer manually based on info provided within the package.

User Interviews

For this project, we interviews a multitude of individuals, like the project lead, who gave us a general idea of what the app currently does, as well as giving us access to internal versions of the app that had not been released on the app store for the general public.

However, the main user interviews were when we went to the actual fulfillment center and actual met with the returns agents; the people who would actually be using this app when it was completed. The performed a few returns, one for each condition of package that was present at the time, so we got to see how they used the current version of the app, what buttons they clicked each time, what they looked for, etc.

Based on these interviews, we came to a lot of conclusions, as well as confirming or disproving various assumptions.

Findings based on earlier assumptions

Most people will want to click as few buttons as possible. This was confirmed by the project lead, and it was the most important part of the process; cutting out unnecessary time spent on individual orders. With the sheer volume of orders coming in, spending more than 30 seconds to a minute per order adds up fast
There we will be thousands of potential returns for one person to handle, and they will be handled in blocks. This was confirmed by the returns agent and the factory manager. It turns out, the different package states are handled in chunks because they are sorted before the returns are processed. This means that an agent will probably handle 500 or so packages that are Unopened Factory Refused ONLY, or Customer packages ONLY, etc.

This means that we need to add a button that immediately starts a new return in the same package condition without going back to the menu each time; a redundant action if they are all the same type of package.
The packages will arrive in multiple different states. This was confirmed in the four different states the package can appear in, meaning the main menu needs to allow the user to quickly select one of the four options.

2. Planning

Key Takeaways

We created a number of different potential flows to aid us in nailing down the general look and feel of the app, cut out unnecessary screens and menus, and optimize the app's flows to ensure speed and efficiency for users. This combined with the existing knowledge from the users in the fulfillment center really helped us think like a user and confirm any doubts we had with the flows.

Flow Charts

Created our own flow charts based on research to get a better idea of the new app flow

Pain Point Analysis

Reviewed user research findings
Confirmed existing issues in the coupon experience space, and started strategizing solutions

Details

3. Design

Key Takeaways

Once we reached the design phase, we began designing wireframes. This process took a decent amount of detail checking due to the fact that we needed to create wireframes for each of the four flows, in order accurately lay out all the possible user choice combinations, but we still managed to make it into the prototyping phase within 3 days after developing the wireframes thanks to having all the research and user flows laid out.

User Flow

Built out a global user flow that would account for all possible user inputs and page combinations

Wireframes

Produced wireframes for all different flow types; unopened, opened, and customer

Details

4. Prototype & Testing

Key Takeaways

With all the wireframing done, we moved into the prototyping phase, where we began having lots of meetings and very quickly progressed the design to a more finalized state, and went through about 5 iterations before we landed on something that everyone was confident. After this point, it became a matter of fine tuning, as it was just a matter of adjusting button sizes, changing colors, and some smaller text changes in the UI

High-Fidelity Prototyping

Designed 5 different iterations, each taking and improving on the last before finally coming up with a finished design

Style Guide

Created a style guide that was slowly expanded upon as the project evolved

Details

Final Thoughts

With the final prototype complete and approved, once again, I got a chance to look back and reflect on our work. I believe that we met the goals and expectations of relief factor, and delivered a quality product that will really help them process and manage returns more efficiently. This was my first opportunity to work with a full team of designers as well as other UX designers, which MASSIVELY improved the ability to bounce design ideas off people.

It was an extremely fun new look at the UX process, and how it is to work in a team environment, interviewing users and clients and having someone with a different perspective to really narrow down on any details I may've missed. Given that all my previous projects were essentially solo, the difference was practically night and day, and my efficiency improved TREMENDOUSLY

Building an application to help Relief factor manage returns!

Project Overview

Challenge

Objective

Key Takeaways

Project Scope

My Role

Tools used

Team Input

Duration of Project

1. Research

Key Takeaways

Details

2. Planning

Key Takeaways

Details

3. Design

Key Takeaways

Details

4. Prototype & Testing

Key Takeaways

Details

Final Thoughts

Microsoft Coupons

KidZscore

Back to Top