Currently, our system fails to align refunds with the original purchase, resulting in customers accruing interest on refunded items. This discrepancy not only contradicts the principles of financial well-being but also ignores the opportunity to guide users away from unnecessary debt.
The main challenge for this initiative relies on Technical functionality to match refunds with original purchases. But this logic is under a different team and we have little time to find a solution that can adapt to lots of case scenarios so we need to propose a solution from an experience perspective. Of course this approach brought new challenges in the way as there were gaps of knowledge about Core’s team and their capacity to approach the problem that we could only find out once we got the chance to meet with them and discuss our proposal. We also had to take into account different aspects of Refunds such as whether they cover the full or partial amount of the purchase and whether they occur in the same billing period or in subsequent ones. Additionally, we needed to address what occurs when users have already made payments and how the interest already charged is handled.
We initially tried an approach centered around informative push notifications and in-app modals to communicate refund details and its impact to the original purchase, along with actionable steps like requesting credit back or adjusting future installments. This approach was quickly dismissed once we got some early feedback from developers regarding limitations around modals, like their order of prioritization when opening the app.
We then pivoted to a different strategy to communicate this impact through the details screen of the original purchase. As this screen was really old it was also a good opportunity to have an overhaul and improve its design while creating a space dedicated to inform refunds and their corresponding impacts. We introduced a banner on this section to explain how it impacted the purchase, along a redesigned layout that provides clarity on the current payment plan and status.
This proposal was flexible enough and could adapt to every case while also maintaining a controllable amount of variants that could be reused, so we moved to the next step, and after a new round of feedback with stakeholders, developers started refining to later build the front end. Not long after, we got to meet with Back End developers from Core team and we introduced our solution design along with some UX rationale and PRD documentation so they could start working on their technical implementation.
An unexpected turn happened a few days later when Core team came back to us with a really complex solution approach that didn't quite connect to what we had thought. It was already too late so we decided to have a session including Front end and Back end to ideate on a solution that could fit for everyone. This session allowed us to realize there had been a misunderstanding around the requirements presented therefore the technical solution wasn't what we expected. However, there was still a corner case that needed extra care as it wasn’t being covered in the design. So after some ideation we gathered again with developers and came up with a solution for the specific scenario as well: for cases where customers already paid some installment of a purchase and get a partial refund that impacts the amount of interest being charged, we will return interest in a separate transaction.
This solution only works temporally as this information will only be visible in the purchase details once we implement a section for History of Payment plans where this interest can be reflected in the ‘before’ snapshot of the payment plan.
