A three-week UX design sprint for ReturnRunners, a first-mile reverse logistics tech startup in Chicago. Tools used include Sketch and Axure.
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.
User & SME interviews
Wireframes with annotations
Mid-fidelity Axure prototype
Roadmap & future recommendations
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.”
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.
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:
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.
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 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.
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:
We built a foundation of knowledge with domain research, competitor analysis, and subject matter expert (SME) interviews.
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.”
Using that as a base, I dove further into research and found the following insights:
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.
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
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
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:
Taking what we learned from the contextual inquiry and SME interviews, I led a process mapping exercise with Fara to verify what we observed.
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.
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.
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:
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.
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:
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.
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.
Prepare runners to provide services efficiently, effectively, and confidently while also capturing necessary information to make ReturnRunners successful.
Provide only necessary utility when they are on-the-go, while staying portable and compact.
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.
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.
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:
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.
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.
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.
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.
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.
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.
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”.
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.
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.
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:
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.
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.
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.
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.
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:
“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.
“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.”
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.
“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.
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.
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.
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.
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.
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.”