RETURN RUNNERS
Whiteglove Retail Returns
A digital product that summons a return expert to pick up and return retail apparel and goods from the client’s doorstep.
21st Century Shopping
Today, the prevalence of online shopping has revolutionized consumer expectations in the retail clothing market. More than ever, buyers desire the ability to try on items in the comfort of their own home at their convenience.
Retailers bear the financial brunt of this convenience to the customer with upwards of $90 billion in goods returned to stores, yearly. Consumers have discovered the comfort of buying garments in varying sizes, trying them on at home, then returning for a refund.
The return process is where consumers find the tradeoff for that convenience. While they can try clothes on in comfort, they must face the trials of returning these unwantables, either in store or by parcel. Many avoid  either option, and miss out on a refund.
$90 BILLION IN GOODS RETURNED TO STORES, YEARLY
Enter Return Runners
An on-demand, white glove service which returns retail products for a nominal fee. RR picks up returns from clients and returns them  to their appropriate retailer, barring products outside of return policy restrictions.
When RR requested the help of myself and my team, they had no administrative or runner-side products to automate everyday processes.
The Problem
Create a digital interface which will result in greatest optimization of Return Runners platform by finding solutions to improve customer experience, runner efficacy, and data collection.
The Challenge
UX designer and researcher, working on a team of 3 others. My team and I conducted research with interviews, developed concepts, and created a working prototype to meet the Return Runners design challenge.  
My Role
Kickoff
In order to hit the ground running, our design team elected to hold an initial kickoff mtg with RR’s 3 stakeholders, each of whom brought a different concern to the table.
• Maintain branding, focus on maintaining “white glove” brand identity.
• Work with scalability and optimizing the internal operations.
• Augment the return process performed by runners.
When meeting wrapped, my UX team understood the  solution needed to be less about back-end interfaces and more about increasing the feasibility of the Return Runner model. To do that, we would need to strike a balance between varying stakeholder goals and inspiring UX.
To approach a solution, we knew we’d need to become intimately familiar with the Return Runners model. We were invited to observe a return being processed by return runners. Conducting this contextual inquiry was the most informative action we could have taken to wrap our heads around return runners. By observing the run, we were able to immediately identify numerous challenges facing both runners and the business that hours of research could not have surfaced.

It also provided the stakeholders an additional opportunity to talk with us about their vision for Return Runners, and used the run to contextualize their ideas. I believe the extra effort we put in to understand the process established a level of trust and strengthened the relationship with our client.
Return Run
Domain
Domain research filled in gaps left by the interviews. Looking into on demand services, mentions of two-sided marketplace were reoccurring. By definition, a two-sided marketplace is “platform for economic exchange between two distinct user groups that provide each other with the benefits of a large network.” In this model the business is providing a marketplace where consumers can pay for services provided by third parties.
Interviews and Exercises
Interviews were lined up immediately after the kickoff but few generated qualitative data. Insights from one subject would contradict another, some never used the service nor really shop for clothes often enough to be much of an expert. They just didn’t interact with Return Runners in a meaningful way. I saw the need to evolve our interviews to generate something of value.
To understand more, exercises were used in interviews, resulting in SME and stakeholder interviews that yielded insights about Return Runner’s the trajectory towards a “hub and spoke” model, vs. “point to point” which was less logistically sound. “This or that” was another that showed how Return Runner’s brand identity was taking shape in the minds of users and SMEs.  
Research
Understanding 2 sided markets recontextualized the challenge. I realized that the back-end requires two interfaces, one for runners and another for the internal operations. It was necessary to define the platform for each option. What made sense for a runner was a mobile app, they are always moving. Conversely, the business would find  a web app or executable most useful.
I considered that Return Runners needed a means of tracking data valued by retailers and a means to track runners interactions.

A mobile app was the only option that could track the fine details in each run. The runner was the central touch point to the entire platform, a mobile app had the potential to capture every interaction, from navigation times, pickup times, return details, store efficiency, everything up to brands that had the most returns.
Decision: Runner Side App
They were fine with our decision to create a runner app, but they didn’t have confidence in our reasoning. The takeaway from our presentation was that there was a need to improve the runner experience. What they wanted was more detail on how this made business sense, and what results they could expect from implementing our solution.
The mistake was ours, we tried to upsell our idea and failed to speak to client needs. We were going to need a much better way of communicating than “Gee, isn't UX great?” I realized, that up until now, we defended our ideas with theory. Clients aren’t interested in theory, they want to exchange ideas. As designers, my team needed to structure our presentation by discussing our ideas then presenting context for the decision and expected results. Afterwards, facilitate conversation by asking their perspective on the factors that influenced our decision, and our expectations, creating alignment between the client and my team while also giving us better quality feedback.

My team and I were now keenly aware of how to speak with our client, and throughout the rest of the process, we would work to stay aligned with them in this way.
THROUGHOUT THE REST OF THE PROCESS, WE WOULD WORK TO STAY ALIGNED WITH THEM
Design Speak
Concepts
Deciding on a runner app narrowed our scope of exploration. One of the things that came up during the initial kickoff meeting was how to train new runners. In addition to this, we thought about facilitating decision making and finding points for data collection.
I focused on creating a product that could scale with Return Runners by being useful in the present and in the future as practices changed.
I considered the hub and spoke model within which runners that pick up returns wouldn’t be the ones going to the store. My goal was to create a concept built around the decision tree that we knew existed in Sammy and Fara's heads while dividing up the process that a runner goes through between picking up and dropping off.
Another thing that didn't test well was an interaction design built into our checklist. The checklist prompts the runner to check items before leaving with them.
Regardless of hitting X or Check a prompt asked the user to add details. Test participants felt this would be tedious and slow the process.
We asked if we should only ask for details when pressing X, most testers felt the same.
Immediately after we tested our prototypes I began thinking about how to communicate with our client. I wondered if we would have a hard time contextualizing the concepts. I believed the best way to align with our client was to create a diagram to demonstrate different phases of Return Runners future and what business solutions would work best in each phase.
Our solution targeted their current phase, and designed to assist with transitioning to the next phase. Essentially, we structured the ideas we heard from stakeholders, and the client and folded our solution into that structure simultaneously demonstrating a positive result in scaling up.
Immediately after we tested our prototypes I began thinking about how to communicate with our client. I wondered if we would have a hard time contextualizing the concepts. I believed the best way to align with our client was to create a diagram to demonstrate different phases of Return Runners future and what business solutions would work best in each phase.
Our solution targeted their current phase, and designed to assist with transitioning to the next phase. Essentially, we structured the ideas we heard from stakeholders, and the client and folded our solution into that structure simultaneously demonstrating a positive result in scaling up.
Client Alignment
Guidance from Start to Finish
Return Evaluation Assistance
Itinerary with Navigation
Post Return Receipt Capture
The target for a concept was already narrow, so we didn’t need to tighten up our build for the prototype very much. We made sure to ask about checklist to verify the assumption that its functionality was desirable.
Basing it off my team’s concepts, we designed the prototype to digitize the process Sammy and Fara in their head and structured it linearly. It guided the runner through the process, double checking everything before they left for the pickup, guiding them through checking item conditions, requesting confirmation on returns and then asking them to photograph the receipt which would be then managed by an internal system and emailed to the Return runner’s client.
Usability test data showed there were only a few alterations needed to make the product viable. In just a day we created an MVP and prepared for the last meeting with our client.
The Runner’s Fanny Pack
Additionally, I had ideas about how version 2 might take shape. This came from a meeting with the creative director as we were preparing to build our MVP. He asked us to consider alternatives to linear process we created, such as a branching hub.
The creative director argued for giving the user more flexibility in cases where they may need to switch from screen to screen, non-linearly. The app would also be more lightweight and better use estate within various screens, by reducing option redundancy.
I took some time to work with the ideas that came out of the meeting and consider it for presentation as the MVP. Without test data, it was a step or two too far from the prototype. So, saved as version 2, should return runners wish to optimize, they have options.
I’m a proponent of clients keeping momentum after the end of a job. Included in the presentation were details about how the client’s system should collect data and provided them with the graphic as a deliverable, and discussed what their next move was in building out the MVP.
Future
“ECONOMIC PLATFORMS HAVING TWO DISTINCT USER GROUPS THAT PROVIDE EACH OTHER WITH THE  BENEFITS OF A LARGE NETWORK.”
Mac Hanaman - UX Designer and Advocate
Work
Work
About
About