Online Returns for The Home Depot
Project Overview:
The objective for this project was to allow users to return products purchased online without having to go into a Home Depot store. We needed to allow users to submit returns online, where they would choose to ship the products back to The Home Depot, or schedule a courier to pick up the product from their location.
From a business perspective, our goals were to reduce return related customer service calls and reduce the amount of products purchased online to the store. We also wanted to gather more information from our customers and better understand why they were returning products.
Empathize and Define:
To begin the empathy step, team members purchased and returned something online from a retailer of their choice and documented the returns experience. We quickly identified a number of patterns among competitors that would prove useful. For example, almost all experiences followed the same set of steps in the same sequence.
Something like this; What order do you want to return? > What items do you want to return? > How do you want to return them? > Ready to submit?
All of us felt this experience and flow worked well, although it would need to be adapted to suit our needs and the needs of our users. We also set up a number of unmoderated interviews with customers to better understand what they were looking for from an online return experience. This way we could make sure we were going to meet their expectations. We learned a few important things like:
Returns need to be free, users have come to expect free return shipping.
Many users don’t have printers on hand to print return labels, we’d need to find a workaround.
Users expected multiple return methods.
From here, we needed to prioritize and further define the scope of our returns experience. We knew we wouldn’t be able to do everything in our first release, so we organized a prioritization session to further define the scope of the project. We left the door open to explore ideas, but narrowed down further what we would include with our Product and IT partners, what must be included in scope, which features would be nice to have and what could be revisited later. (The same exercise we went through in the wishlist sprint)
Ideating and Designing Solutions:
We started with a quick crazy 8’s sketching exercise, which we decided to simplify to crazy 4’s so that our business and product stakeholders could get more involved and share their ideas. Our sprint team met for 30 mins, taking 5 minutes to set up the exercise where we committed to keeping our sketches simple and only focusing on a single step each. Using only pen and paper to keep a level playing field, each team member sketched 4 iterations of their ideas, trying new things and finding one new way to improve our design in each sketch. We took the last 10 minutes of the meeting to explain our ideas and vote on our favorites.
From this point the team was feeling pretty confident in our direction, so we sketched out our ideas and collaborated together to design mockups for all necessary scenarios and stitched them together to build a prototype. Here are the key steps and actions needed to accommodate both users and business:
Initiate a return from the order details page.
Select specific products and quantities from the order to return. (Our pro customers like general contractors, plumbers or electricians who are frequent buyers for their businesses would often purchase too much for a job and have products left to return)
Select the return method, users needed to choose if they’d prefer to drop off at a courier location or schedule a courier pickup.
Remind users that products could be returned to any Home Depot store and provide a map of all of the closest locations.
Accommodate extra large items like patios, hot tubs or appliances. We needed to use a special courier that could arrange to pick it up. These couriers would contact the customer directly and needed the customers contact information.
Accommodate customers who did not have printers to print our return labels. We added an option for users to have labels provided by the courier at pickup or drop off.
Provide users with instructions and details about their return. Users needed to print and attach a label to a package they’ve prepared for the courier and know where to go to drop off or when the package would be picked up.
Finally and most importantly, users needed to know how much money they’d be getting back from their return and when they’d receive the refund.
Testing:
Test Setup
We mostly needed to understand if customers could use this feature and if they could complete all of the above actions. Just like in wishlists we organized a number of unmoderated usability tests to have users interact with our prototype independently and complete tasks and answer questions.
We organized a test script, converting all of the main actions listed above into specific tasks. In this case, everything was new so we didn’t need to give too much direction on what users should interact with but focus them on specific scenarios they found themselves in. We gave them an order they had purchased and a list and amount of products they needed to return. In our scenarios some of these users preferred to drop it off at a courier location, others needed the product picked up. We observed and took notes as users attempted to complete their objectives, paying attention to where users hit roadblocks or experiences pain-points and when they were successful.
Reviewing Results
To synthesis our data, the team met for an affinity mapping session where we organized all of the notes looking for commonalities between them and grouping them into themes. By doing this, we could see where groups of users were running into the same issues and where users were able to find success unanimously.
Issues we identified in our first round of testing were:
Users were not clear always clear on how they should package their return, questioning if they needed to use the same packaging the item was received in, (which they did not) and if all of the printed return labels needed to be used (which they did).
Users also wanted to know exactly when they should receive their return. We were able to issue refunds as soon as the user the product was with the courier, a huge competitive advantage missed.
Iterating and Retesting:
After sharing these insights with our stakeholders, we aligning on a new direction to address the pain-points we found. We made two major changes:
We allowed users to choose how they would be packaging their return, allowing them to select the amount of boxes they needed to package their return and provide the same number of shipping labels.
On the users return confirmation, we let users know that they would receive a refund as soon as the courier scanned their return label.
We repeated the testing process with these new iterations on our designs and found them to be quite successful. Users were easily able to choose how they should package their return and clearly stated how many labels they should get for their return order.
Users were also delighted to know that they would receive their refund as soon as their packaged was scanned by the courier. Many other retailers need to receive the product before issuing a refund. This was a great development for the business as well, as it encouraged customers to be punctual with their returns.
Handoff
Once we were satisfied with the experience and were sure that all user issues were solved, we prepared the project to be handed off to product and development teams. This includes a long list of UI deliverables and documentation to create to make sure the transition between teams is smooth. Here are just a few examples:
UI designs for all potential scenarios: Different products types, variations in quantity, single item returns, orders with pending deliveries, notifications and error messaging are just a few examples.
Copy documentation, including all new copy created for the project and their translations.
AODA/WCAG compliance requirements like icon, link or image alt text where required.
Updated and functioning prototypes to document intended flow and demonstrate animations.
