Context
Tymit is a revolutionary instalment-based credit product with commitment to reshaping conventional paradigms and putting the focus on transparency and flexibility for customers. It operates with two other brands, so any change or addition we implement must consider its effects and adaptability to these other brands.
Problem
Currently, the 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.
Why is it a problem?
- We need to keep aligned to regulations from the FCA and act on behalf of customers so they don’t accrue unnecessary debt.
- This generates confusion for customers, increasing time spent by agents to solve queries, replan transactions or issue credit.
Objective
The main challenge for this initiative relies on Technical functionality to match refunds with original purchases. But this logic is under a different team (Core) 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 and later align with the other team.
Success criteria
Before diving into research to have a better understanding of the problem, we defined with Product Manager and Squad Tech Lead what results we expect to achieve:
- Guarantee that our system acts on behalf of customers in cases where balance can be covered by refunds.
- Decrease amount of queries to Customer Service regarding refunds.
- Ensure customers receive clear information and available actions when a refund gets applied to a purchase.
We also listed how we are going to track the results of the implementation:
- Tracking contacts to CS related to refunds.
- Tracking amount of users with refunds not matching the original purchase (should be 0%).
- Amount of users that change their payment plan after getting a refund.
Once we gathered and included all the information about objectives, success metrics in our PRD, together with PM and Squad TL we wrote down all the questions we had and steps to follow next.
Research
Current experience design analysis
We started by analysing the current experience to understand how our customers go through the journey of receiving a refund. As these don’t match or get connected for the user is always the same behavior: they receive a push notification advising of the refund, and the amount they are getting as credit. The original purchase doesn’t get impacted, therefore in cases where the user selected an interest-bearing plan they will still pay interest for the following months. We found an additional problem here and is that we don’t inform users about the situation, they may assume we are going to act on their behalf, which of course we should, so they don’t even check the original purchase or its plan.
We also had some feedback from Customer Support about customers’ queries mentioning getting confused on the information presented, “if I returned this purchase and got a refund, why can I still select a plan to pay for it?” or “Am I still getting charged interest?” This also raises a new task for agents, as they need to either return interest manually or replan a purchase so it doesn’t accrue interest in the customer’s account.
Journey mapping
We then moved to mapping journeys for every type of refund. This helped us identify 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.
Ideation
Once we had defined what needed improvement and we understood all posible scenarios, we moved to ideation where I collaborated with Content Design. Our first approach was directly related to communication so we proposed a solution with pop-up modals to inform users about the refund and its impact to the original purchase, besides offering actions to change their payment plan in some cases.
Once we had the proposal we met with our team’s developers and Product Trio, and we had to quickly dismiss the proposal because of tech debt, and constraints when trying to prioritize modals in the app. We also realized this solution would also fail as users wouldn’t have access to the information after closing the modal.
1st iteration
So we moved to the next iteration where moved the focus to the transaction details screen, it was a really old screen so it was a good opportunity to re think its design and create a space to inform about refunds.
We used components from our Design System to create sections in the screen, this helped in the hierarchy and narrative of the information being presented.
Prep for delivery
Once we mapped again all the cases and checked the solution was flexible and could adapt to all scenarios, we had some sessions with different stakeholders including our partner, we moved to the next step to test with users and validate hypotheses.
We also started a prep for delivery phase, refining with developers, documenting all decisions, guidelines for UI, icon definition, besides conclusions from user testing that could be taken for future iterations.
We also prepared Lokalise keys to manage content and documented all decisions made during the definition of the initiative including UX rationale, UI specific guidelines, icons definition and analysis and conclusions from user testing.
Additional iteration
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.
Hand-off and implementation
We’ve split the execution of changes in four phases, this way we make sure every scenario is correctly developed and tested:
- Transaction details redesign to include new components from Design System.
- Implementation of Refunds that happened on same billing period.
- Implementation of Refunds that happened on next billing period including cases with returned interest.
- First experience modal to give users visibility of the changes.
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.
Learning & thoughts
One of the most relevant learnings from this initiative is the importance of alignment and communication: even if the other team involved couldn’t work at the same time as us because of roadmap priorities, all decisions made should have been better documented and communicated to our colleagues. Also, I think having specific sessions to discuss about every case scenario before they started their side of the work, could have helped to make sure everyone in both teams were aligned.
Another remarkable aspect from this case study is the importance of collaboration: getting the chance to talk to our colleagues in Customer Support team to have a closer understanding of customer’s pain points, also having the opportunity to discuss with developers about proposed solutions and get their insights in early phases of the process.
