ReturnRunners

“The easiest way to make your local and online returns.”

Overview

Project info

A three-week UX design sprint for ReturnRunners, a first-mile reverse logistics tech startup in Chicago. Tools used include Sketch and Axure.

Summary

ReturnRunners offers customers a hassle-free way of making retail returns. Working on a team of 4 UX designers, we conducted user research, identified users needs and goals, and designed a mobile solution that provides their runners with the information they need to return retail items. This resulted in a streamlined pick-up and return process that addresses scalability and captures the business metrics they need.

Artifacts & deliverables

Research plan
Competitive analysis
User & SME interviews
Journey map
Wireframes with annotations
Mid-fidelity Axure prototype
Taskflow
Data flow
Heuristic evaluation
Roadmap & future recommendations

Learning about the client

About

In their own words, ReturnRunners is an…

“On-demand, white-glove return service for retail merchandise. We offer customers a hassle-free way of making retail returns and create value for stores by helping expand their customer service offerings, streamline their reverse supply chains, and mitigate return fraud.”

How ReturnRunners works

1. The customer pays $9.99 for the first item, and $0.99 for each additional item, and schedules a time for pick-up.

2. A runner is assigned and picks up the customer’s items during the pick-up window.

3. The items are returned and the customer receives a confirmation email within 24 hours. The refund goes back on the original credit card.

Background

Our client, Fara Alexander, started the company after her wedding. She saw the number of items she had to return piling up, but didn’t have the time to return them herself.

Regarding the service, she shared the following information:

  • Online shopping has changed customers’ shopping habits, resulting in more returns, particularly for upper middle class urban women, between the ages of 28-50
  • Customers want a white-glove service to return their purchases without having to return to the store themselves
  • Customers don't want to spend time inputting info, so runners will gather the inputs
  • No major competitors offer similar return services
  • The demand for returns will allow the service to grow to support a two-sided marketplace
  • The core problem they needed to solve was the logistics of picking up and making returns

Assumptions to be validated

I believed that customers expected an economical return service for $9.99 rather than a white-glove service. I was skeptical that the demand for retail returns would sustain a network of drivers like Grubhub or Uber. I also expected customers to be accustomed to providing required return information up front.

Their goals

As a small startup, most of their team currently pitches in to run returns when needed, including Fara. Ultimately, they want to grow a two-sided market to allow third-party contractors to pick-up and run returns on demand, becoming the reverse supply chain partner to retailers. This would also include point of sale opportunities where retailers could offer customers a ReturnRunners “insurance” during checkout. To build a two-sided marketplace, they need to provide their runners a better way to serve their growing customer base, while making their service scalable and sustainable.

ReturnRunners' strategic vision

Phase 1
Consumers
  • Develop loyal group of initial customers
  • Brand awareness
  • Soft launch
Phase 2
Consumers and retailers
  • Activate POS opportunities
  • Technology integrations
  • Last mile and reverse logistics

Their needs

ReturnRunners had customer-facing app and website, and requested a backend platform to handle the logistics of fulfilling orders. They needed a solution to streamline and automate the runners’ manual process to handle more orders per month. They also wanted to make their customer-facing app more user-friendly.

The original website and iOS app allowed customers to schedule a pick-up.

Conducting research

Objectives

As a guy who has never worked in retail, I didn’t know much about the fashion landscape or retail return industry. However, my industrial engineering background and logistics experiences equipped me with the tools to improve processes and understand supply chain management. As a team of 4 designers, we set out to learn more about ReturnRunners before we jumped into designing solutions. Using the 3C's model, we wanted to understand the following: 

  • The retail return business: the domain and industry, competitors, and understanding their goals of scalability, sustainability, and growing a two-sided marketplace
  • The runner: their needs, frustrations, and process
  • The customer: their needs and expectations of the experiences

Learning about the retail return business

We built a foundation of knowledge with domain research, competitor analysis, and subject matter expert (SME) interviews.

Domain research & competitor analysis

I took the lead on domain research, leveraging the expertise of a friend who had co-founded a startup that operates a two-sided marketplace. The key takeaway from my 1-hour meeting with him was that for ReturnRunners to succeed, they needed to prove the viability of their idea.

“The major need for a startup like ReturnRunners isn’t developing a logistics algorithm at this point, it’s building the customer base and doing whatever is necessary to prove that there is a sustainable business behind the service.”

—Sameer

Using that as a base, I dove further into research and found the following insights:

  • The goals for an early stage startup: to stabilize the business model, tweak the business in response to new information, and secure the initial stream of revenue to sustain your business long enough to make scalability relevant. Data collection and tracking is a major component in proving the business model and is used to guide any changes.
  • Operating a two-sided marketplace is the same as running two businesses, where both depend on each other. This requires a large enough base of loyal users on both sides and a careful balance of features and offers on each side.
  • Scalability is driven by finding efficiencies in distribution as the network grows. The solution needs to be flexible enough to allow for changes to the distribution model, and needs to consider each touch point between the customer, retailer, and future partners.
  • With no major direct competitors, ReturnRunners has found a gap in the retail return space to pick up and return customers' unwanted items. However, they have potential competitors to keep in mind as they begin to scale.

empathizing with the runner

With a firmer grasp on the domain, the team turned their attention to better understanding the runners who return the items. Through contextual inquiry, further SME interviews and process mapping with Fara, we learned more about the process and the needs and frustrations of the runner.

Contextual inquiry

The team joined Sammy and Fara on a pick-up and return run to observe their process. We watched as the runner picked up 12 items, valued at $300, from a repeat customer, and returned the merchandise to Macy’s and Old Navy. Joining the runner on their day-to-day tasks allowed us to learn about frustrations that the runners had glossed over in initial interviews.

We also witnessed some runner frustrations during this run:

Manual input of addresses and contact info

A second runner drove and stayed in the car due to lack of parking

Item picked up outside of return window due to lack of error-proofing

Moderate wait for return due to busy time at the retailer

The runner had to arrange a return trip to the customer to drop off store credit

Runner manually compiles a confirmation email with a photo of the return receipt

SME interviews

6 Industry SMEs
3 Logistics professionals
2 Retail SMEs
1 Online retail owner
6 ReturnRunner SMEs
3 Runners
2 Interns
1 Event coordinator

We interviewed SMEs in logistics and retail, and runners to better understand their frustrations and needs. Here's what we heard:

“There are few things better than the truth. The truth is what it is, and there's nothing you can do about it. You manage expectations by delivering information as real time as possible and getting that information out of the digital environment and into the human environment.”

Josh M., Logistics SME
“[By setting expectations]... in the interactions with the customer, it comes off as really knowledgeable—we know what we're doing, we know the stores well, and we've developed a relationship.”

Alexa C., Runner

Finding insights

We found common themes by reviewing interview notes and whiteboarding.

We learned more about our runners and dug into their frustrations. From our industry SMEs, we learned to consider the following aspects to make the service successful:

  • Finding network efficiencies means moving from a point-to-point distribution model to a spoke-and-hub model when their volume can support it.
  • Communication and transparency is key to managing expectations, whether it's internal to resolve issues quickly, or client-facing, to build and maintain trust.
  • Customers want a seamless experience. Fewer mistakes equals more money.

Process mapping

Fara described the steps of making a return run as we documented the frustrations and investigated root causes.

Taking what we learned from the contextual inquiry and SME interviews, I led a process mapping exercise with Fara to verify what we observed.

The runner's journey (click to enlarge)

By working with Fara, and documenting the current state steps, this allowed us to pinpoint the pain-points, and discuss root causes to understand the opportunities for improvement. This helped us set expectations with Fara, ensure that she was aligned with the process, and earned us her buy-in.

Customer insights

With our focus on improving the runner experience, we needed to understand the customer and improve the inputs into the process. While our SMEs and ReturnRunners staff told us a bit about their experience and insights about their customers, we wanted to hear it directly from potential customers. We interviewed 19 shoppers in Chicago’s retail shopping areas, the Shops at North Bridge and Block 37 to get a representative sample of their user base. We learned about their shopping and return habits, and the information they would provide to a return service.

Guerilla interviews

I interviewed potential customers on State Street.

We found that most users rationalized the return run price by taking into account their time or the expense for an Uber. And with other on-demand services requiring information to be provided, users had no issue providing the information needed to streamline the return process, including:

  • Personal information (name, phone number, email address)
  • Pick-up information (time and date, pick-up address, special instructions)
  • Return purchase information (item information, reason for return, store, date of purchase, photo of receipt, payment method, and refund method)
  • Payment information (payment method to pay for the service)

Of the 19 users interviewed, all of them said they’d be comfortable providing this information, and 17 of the 19 said they could see themselves using this service. This meant that standardizing these inputs from the customer would resolve some of the major frustrations runners were encountering.

What we learned

I facilitated an affinity diagramming session with the team to gather insights.

We uncovered a lot of information about the business, runner, and customer. We found that we couldn’t just design an app without considering business needs, because for the service to be scalable and sustainable, the solution would need to provide the metrics to prove or pivot their business model. Additionally, we found:

  • Improving and standardizing inputs from customers is just as crucial to improving the process as developing a tool, and we needed to determine how those inputs would be gathered
  • Enabling runners to access resources when they need them would reduce the frustration of having to recall specific return policies from memory
  • Providing the runner with tools for transparency and communication would enable them to provide users with a more seamless experience

Defining the problem

Convergence and alignment

With the learnings we gained through research, interviews, and our process mapping exercise, we converged on the biggest problem to solve for our client. While we saw the importance of fixing ReturnRunner's order intake process by standardizing the inputs from their existing app and website, their greatest need was a tool to help their runners during the return process to gather the information they needed. Our client agreed.

The problem

Service-minded runners need to confidently make informed decisions on-the-spot, providing excellent and personal service to create a mutually beneficial relationship between runners, customers, and retailers. They need a digital tool that will aid in collecting, collating, and organizing the information during the return process.

Guidelines

Dress for success

Prepare runners to provide services efficiently, effectively, and confidently while also capturing necessary information to make ReturnRunners successful.

runner's
fanny pack

Provide only necessary utility when they are on-the-go, while staying portable and compact.

A face you recognize

Assist the runners in providing the friendly and personal service that are a part of ReturnRunners’ brand values, to build lasting relationships with their customers.

Brand ambassador

Enable the runner to represent the retailer’s values in being the first line of defense in screening for return fraud.

Our problem statement and design guidelines clarified our focus and gave us a way to align with our client on our direction and approach to get to their second phase.

Diverging concepts to discover solutions

Concepting

With alignment and support from our client, we used the information we learned about the runner’s process to brainstorm different ways to solve the frustrations runners encountered. We used these concepts to validate our ideas with users and focus our direction before we invested time in building a clickable prototype.

We brainstormed and each developed a concept with a particular goal to test, based on what we learned from runner interviews. Here are the four concepts:

Concept 1: Personality

This concept allows the runner to establish a relationship with the customer through runner profiles. Customers would be shown a profile for the runner which showcases their personality and personal style, in addition to ratings, reviews, and accolades. This concept pulls inspiration from Uber’s driver profile with the intent to gauge the importance of relationships in the service.

Concept 2: Modal

This concept features a pick-up and return mode. The focus was on moving into a spoke-and-hub model in a two-sided market. The runner picks up an item from a client, is guided through the pick-up process and then is given the option to return to the central warehouse or drop it off at a store. This gives ReturnRunners flexibility in their return process as they scale. This concept is based on Lyft’s app design, and tests the runner’s interest in splitting up the pick-up from the return.

Concept 3: Efficiency

This concept focuses on making the pick-up process more efficient and streamlined. Return information would be provided by the customer via the customer-facing app or website, and the runner would use the app to verify the provided information. This would require the customer inputs to be standardized, and error-proofing to be automated based on the inputs. This would keep the runner’s process more streamlined, with a more flexible focus on the on-demand aspect.

Concept 4: White-glove concierge (MY CONCEPT)

Based on their brand values, I created a concept that would give the tools that make the runner a concierge providing white-glove service. This mitigates the need for the customer to input more detailed pick-up data, with the runner becoming the primary interface with the customer to gather and verify that information on pick-up. This would be paired with resources like return policies, and allow runners to capture additional return information for analytics, and included a detailed itinerary for the runner’s day.

Concept testing

We tested these with 3 runners, all familiar with running returns. We gained an understanding of their needs and how to best prioritize features in the prototype. We utilized both an interview script and think-aloud protocol.

“[In Concept 4], the runner shouldn’t necessarily need to ask them for reason for return… We don’t want to seem survey-ish.”

Sammy G., Runner

Overall, testers said the data collection process shouldn't affect efficiency, which verified the need for standard inputs from the customer. Otherwise, each tester seemed t differently to each concept.

  • The first runner liked the simple checklist of Concept 3.
  • The second runner wanted a more personalized experience with the profile of Concept 1, but also wanted the itinerary and path of customers called out.
  • The third runner liked aspects of each, especially those that separated the pick-up from the returns.

The a-ha moment

When we regrouped to debrief, and really figure out what this meant for our concepts, we were perplexed by the different responses, as they didn’t provide us a clear direction. As we split up to wrap up our own notes, I began to look at the root cause for the responses and began to consider their motivations. It was then that it clicked for me. The runners we tested didn’t necessarily have different preferences for the concepts; they had different perceptions of how the business model should work. With that in mind, we were able to understand the context for why they responded differently.

  • The first runner who preferred the simple checklist didn’t see the need for a runner profile, saw the service “like getting an Uber”, where it would be an on-demand two-sided market being run point-to-point.
  • The second runner liked a more personal experience with the profile, but also wanted an itinerary with a path of customers called out. She saw the service as one that was scheduled, rather than on-demand, with a spoke-and-hub model.
  • The third runner liked aspects of each, but her choices were motivated by a spoke-and-hub model, where items would be pick-ups and returns were separated, with a more efficient process. Once items were picked up, they could be batched at a central location, and returns done separately and more efficiently.

ReturnRunners considered multiple business models and needed a roadmap. For our solution to be a success, we needed to define the intermediate steps in their roadmap to get them from their “Phase 1” to their “Phase 2”.

Designing the roadmap

Based on this information, I plotted out a matrix of different business models they had discussed against how those needs would align with the needs of the customer, runner, and operations hub. Taking the different business models, I looked at the needs of the customer, runner, and business and mapped out an updated roadmap with intermediate steps.

Original roadmap

Phase 1
Consumers
  • Develop loyal group of initial customers
  • Brand awareness
  • Soft launch
Phase 2
Consumers and retailers
  • Activate POS opportunities
  • Technology integrations
  • Last mile and reverse logistics

Updated roadmap

Phase 1
Current state
  • Point-to-point
  • White-glove service
  • Non-standard orders and data varies from multiple sources
Phase 2
Spoke-and-hub
  • Pick-ups consolidated at a distribution hub prior to returning
  • Hourly/trained runners
  • 100-200 orders/month
Phase 3
On-demand
  • On-demand pickups and just-in-time scheduling of runners
  • Runners are 3rd-party contractors
  • Expanded customer base supports second side of market
Phase 4
Direct returns
  • Items can be returned directly to reverse supply chain
  • Items are rated, and return path based on rating
  • Additional POS opportunities and partnerships

Validating our direction

While the different models discussed could coexist, they each had different prerequisites that needed to be met before they could be implemented. It made sense to separate models into different phases based on those conditions. With a spoke-and-hub model having the lowest barrier of entry, it could be implemented first as the order volume grew to 100-200 orders per month, or about 7 orders a day. Subsequently, the on-demand Uber-style model would be pushed to Phase 3, when greater volumes of orders would support a secondary market of 3rd party on-demand runners. Additionally, the partnerships with retailers and other POS opportunities would move to Phase 4, as that requires even greater volumes and proof of a sustainable business model.

With this epiphany, we shared our concepts, the feedback, and the updated roadmap with Fara and her team. It was clear from their response that they hadn’t yet discussed this, but agreed that we considered their business needs and presented something valuable. With this alignment and connectedness to our client’s business model, we were ready to move into prototyping the solution.

Building the solution

Converging features

By driving towards a spoke-and-hub model and pushing the two-sided market to a future step, we simplified the decisions we needed to make to build our prototype. We based our prototype on Concept 3 and incorporated other features that testers responded well to: the itinerary, navigation, and resources and tools the runner would need during pick-ups and returns.

Our goal was not to reinvent the wheel with our prototype, but rather to provide a tool that would be useful to the runner and flexible enough for any changes in their process. We took this opportunity to revisit our competitor analysis, and looked at new indirect competitors to help us determine some additional ways to build these features. We looked at:

  • Google Maps for their itinerary and preparation
  • Waze for their parking and traffic/route optimization
  • Lyft for their UI elements, customer contact, and flow
  • Receipt Pal for their receipt capture and AI data extraction

Prototyping

Using Axure, we delegated and built the prototype, creating masters to ensure a uniform and cohesive design. Based on our concept testing insights, we added in features and mobile patterns pulled from indirect competitors. Our design worked with the current point-to-point model and the spoke-and-hub model that ReturnRunners will employ as they scale.

As process steps are completed, the app would capture valuable metrics, including the distance traveled, the number of customers served/items picked up, and task durations. With these metrics, ReturnRunners would be able to calculate the runner’s efficiency, the logistical efficiency, as well as network utilization rates to prove or change the business model.

Runner's efficiency
# orders picked up / hr
# items picked up / hr
# orders returned / hr
# items returned / hr
Logistical efficiency
Total drive time
Average drive time
Total distance
Average distance
Network utilization
# of orders
# of items / order
Total value of order
Average value of item

In addition to building out screens for our prototype, I knew it was important to show how the data would flow throughout the app. I built out a data flow diagram with the screens showing how various business metrics would be captured throughout to support the business model.

Usability testing

1 Stakeholder
1 ReturnRunners advisor
Review and validate data metric requirements
5 Usability Testers
1 Runner
1 Retail SME
3 Tech entrepreneurs
Test functionality and usability of prototype

Stakeholder review

Taking advantage of the opportunity to engage with Phil, ReturnRunner's advisor, I reviewed how the app would address their business requirements, and utilized the data flow diagram and prototype to demonstrate how each metric would be captured. Phil was impressed by our work and shared his approval.

USER TESTING

With Phil's approval, we shifted our focus to usability testing. We wanted to see if our app was intuitive to use, and if the task flow made sense to new users given the context of their role.

What we learned

Testing our prototype showed us some key insights. Overall, the design was intuitive and easy to use. But there were a few improvements testers wanted:

Pick-up list
“Why are you forced into doing the Nordstrom items first?”

—Andra, Retail SME

We were focused on testing the flow, and didn’t do enough to ensure the app would account for all states of design. The app would need to be flexible enough for runners to be able to make their own choices instead of being forced into a specific route or order of events, especially when there are more pick-ups to handle, i.e. handling the "too many" state. We needed to consider all states when designing the navigation, pickup flow, and help resources.

Resources
“I’d like to see a note on Nordstrom about the store location and what their store hours are.”

—Disha, Tech entrepreneur
“Having the return policy earlier… as a runner, that would be a good thing to reference.”

—Sara, Runner

Users gave us feedback on what resources they needed and when, helping us understand which tools and resources need to be easily accessible by runners.

UI elements
“I would have thought this icon pulls up an image of the receipt.”

—Andra, Retail SME

In the return flow, a user was confused by the icons for return policies and receipts. UI elements needed to be used strategically and intentionally to prevent confusion.

Our solution

Based on usability testing feedback, we updated our designs and shared our findings and solution with our client. By using our solution, the app delivers information in real-time, providing notifications to the customer on the runner’s progress, and allowing for easy communication between the runner and the customer or ReturnRunners’ operations team.

  • Our solution reduces manual inputs, and provides the runner with tools to address problems as they arise.
  • By offloading inputs earlier in the process, information can be verified, errors can be mitigated and expectations can be set from the get-go for returns.
  • By embedding flexibility in the distribution model, our solution enables ReturnRunners to move to a spoke-and-hub model, which can alleviate the issue of wait times in stores, by batching returns and scheduling returns at off-peak hours.
  • Navigation tools that can be leveraged to help with parking; Waze API integration can address this issue.

While fixing the customer-facing app was not in our scope, we provided ReturnRunners with a heuristic evaluation of the app and website, and with user research on the information customers would provide. By improving the inputs, and automating the manual tasks involved in performing a return, we reduced the risk of human errors and proposed ways for ReturnRunners to provide a more effective, efficient, and reliable service to build better customer relationships through trust and dependability.

A walkthrough GIF of our final prototype. Check out the final prototype here.

We provided ReturnRunners with recommendations including a list of unaddressed edge cases, such as non-returnable items, or cash or gift cards that need to be returned to customers. Taking these edge cases into consideration would go a long way to ensure that runners can handle these issues confidently when they arise.

Client reception

Fara and her team were very pleased with the research, solution, and roadmap we presented. We successfully synthesized their business concerns and provided a way for their runners to be able to efficiently serve their customers as they continue to scale.

Tasty thank you gifts from Fara and the rest of the ReturnRunners team.

Lessons learned

Conclusion

Prior to this project, my knowledge of the retail industry and retail shopping habits was quite limited. While I thought I wouldn’t be part of the target demographic, I was able to learn from users about their needs, and design a great solution for them.

By continuing to ask questions, I learned to dig deeper than the client's asks. Uncovering user frustrations wasn't enough. We needed to understand the root cause and context around the problem, and relate it to their needs as an early stage startup looking to grow a two-sided marketplace. This helped me build rapport and frame our solution in a way that resonated with them. It reaffirmed what I heard at a talk about leveraging the value of UX—“If you want people to understand the results, involve them in the process.”