TradeMe Ltd: Designing a returns experience for New Zealand's primary online marketplace.
Overview
An academic project for an industry partner with the objective of researching and designing a returns process for an E-bay like company that holds no inventory as the transaction facilitator.
The Team
I had the opportunity to work with two other UX designer masters students and a Sr. Product Design mentor at TradeMe Ltd. The three of us collaborated on all aspects of the project, and checked in with our mentor periodically.
My Role
-
UX research (User Interviews, personas, co-design workshop)
-
UX design & prototyping (Whiteboard wireframes, Figma high-fidelity, User testing)
-
Project documentation
-
Project Management / Stakeholder Management
Project Timeline
Problem Space
The client does not currently have an established centralized process to return items purchased on their online auction platform.
The client is the transaction facilitator between buyers and sellers and holds no inventory of it's own. Their customers include both buyers and sellers.
​
What users experience today
​
Buyers are required to contact individual sellers via email to try to return their item. This could result in a frustrating, time-consuming, and inconsistent experience.
​
Hypothesis / Assumptions
​
Buyers will benefit from a standardised and streamlined digital returns process. They will feel more confident when purchasing items by knowing they are empowered to initiate hassle-free returns through an easy, consistent, and centralised returns process.
Sellers will benefit as a result of increased buyer confidence, resulting in more sales.
Although there may be short term costs associated with this, the client facilitator would benefit from overall increased sales in the long term due to increased customer loyalty and sales conversions for those who avoid purchasing items when there is no standard return policy.
Competitive Analysis
Because the client does not currently have a centralized returns process, we believed it was beneficial to do competitive analysis before user research. This helped provide us with valid industry best practices and potential pain points for returns user flows. Our client agreed this was a good starting point.
We conducted a returns competitive analysis process for:
-
Amazon.com
-
Theiconic.co.nz
-
Ebay.com
The competitive analyses included a deep dive on the following:
-
Review and UX teardown annotations of the entire website’s return policy
-
Review and UX teardown annotations of user flows initiating a return within and outside of established return windows
-
Heuristic analysis of the overall competitor's returns experience
Assumptions after Competitive Research
​
The following themes emerged after a affinity mapping.
-
Users want a clear and “hassle-free” returns process and policy.
-
Users don’t want to justify why they are returning something.
-
Users expect clear communication from a seller once a return has been initiated.
-
Users need a clear call to action.
User Research, Methods, and Insights
Personas
​
We started by creating personas to help us think about the different types of users who
might purchase items from our client's platform, and what their needs might be. The biggest value here was that it put us into a different frame of mind to help us think of different types of users so that we can design for the client's diverse user base, and not for ourselves.
On Street User Interviews​
​
We interviewed 11 groups of people around the Wellington Harbour about their return process experiences, pain points, expectations, and preferences.
We gained new insights in addition to proving some of our original assumptions.
Users mentioned Amazon, The Iconic, H&M, and ASOS as websites with good return policies. Coincidentally, we already performed competitive analysis on two of these, which can help serve as good examples for best practices.
What users say “Hassle-free” returns means to them:
-
Free shipping
-
Transparency and good communication
-
Consistent, clear returns policy and process
-
Status updates and tracking
User Co-Design Workshop​
We conducted a co-design workshop with 5 users to test our insights and assumptions from on-street interviews & competitive analysis.
Together we built an ideal customer journey map for an online returns process.
Co-design Insights​
-
Users expect free return shipping.
-
Users do not want to communicate back and forth to justify a return.
-
Users want to be aware of the return rules and returns process prior to a purchase.
-
Users are less inclined to make an online purchase if there is no returns policy or process established.
-
Users appreciate clear communication and return status so much that they value it over the time it takes for the return to get processed.
Design & Prototype
*Note: Set prototype to "Fit Width" setting if needed
Objective
​
Create a familiar returns process that is tailored to the client's business model, meets buyers needs, and also appeals to sellers.
​
Outcome
​
We leveraged the insights we gained from our research to design a solution that meets each party’s needs, with the primary focus being on the buyer due to time constraints.
Features​
​
Design a “hassle-free” returns process for buyers:
-
Free shipping
-
Transparency and good communication
-
Consistent, clear returns policy and process
-
Status updates and tracking
Motivate sellers to opt in to the new standard return policy:
-
Reduced seller fees for opt in
-
Increased sales over their competitors who opt out
-
Allow sellers to opt out of the policy: Design two return flows - one for opt in, one for opt out
Create "upsell" opportunities for the client facilitator:
-
Use the client's existing courier service for return shipping
-
User conversion - attract users who avoid sites without return policies
-
Strategically place CTA’s for shopping in the return flow
Wireframes & User Flows​
​
We started with whiteboard wireframes put together as a team, and then a user flow diagram was created by referencing our wireframes.
Product​
​
Full prototype available upon request.
User Testing & Iteration
We conducted two rounds of user testing. Each round of testing gave us new insights and feedback that we used to iteratively improve our prototype.
​
In our first round of testing, we discovered that users were having difficulty finding the return tracking page. Also, the courier booking flow was not intuitive and didn’t fit in with the rest of our design.
​
We made changes based on this feedback and re-tested, getting much better results the second round.
Reflection
This was a really rewarding academic project. What a great opportunity to be able to work with this kind of industry partner. We were especially lucky to be able to partner with a
Senior Designer who spent a lot of time with our team as a mentor and really seemed to care
about our growth and success on the project.
​
What I would do differently next time
​
We conducted on street interviews and a user co-design workshop that were both buyer oriented to come up with the ideal return process together. Although these research methods both gave us some great buyer insights, it would have been better to spend half that time with sellers. Our end product made a lot of assumptions about sellers that might have ended up not being true. Through this I learned you should not only spend your research time solving for one user type if multiple are impacted.
​
What I learned
​
I learned how to prototype as a design team in a single Figma work space. Prior to this I had only prototyped in Figma individually.
I also learned what it’s like to be a designer in a company, having visited the client's office on a weekly basis. I had the opportunity to conduct on-street interviews (a rewarding, but intimidating experience!), and perhaps most importantly, that the same research techniques won’t always work for all projects. (I.E. the co-design workshop gave us some insights, but might be better suited for improving existing product features people are already familiar with).
Finally, I learned that even if the research leads you to a specific insight or solution, there will be business objectives, context, or priorities that may require you to ultimately take a different design path. These edge cases should be prioritized during discovery if possible, however you don't know, what you don't know.