PicPay
ROLE
Product Designer
Background
PicPay is a digital wallet and banking app. It offers bill payments, Pix, money transfers, CDB investments, and credit/debit cards. Users can also manage phone top-ups, gift cards, and installment payments for Pix and bills, with built-in financial tracking and cashback rewards.
OVERVIEW
In 2021 GDPL (General Data Protection Law) went into effect in Brazil, with that also digital product had to be compliant with this new law.
THE PROBLEM
When I joined Kavak I had several meetings with our CPO and interim Product Manager for Warranty and with Customer Relations team.
They had a list of several problems that were causing concern inside Kavak operations.
Users were giving up reporting a problem and booking a visit to a Kavak hub because they could´t get past the first screen, that was causing an overload of calls which I later found out that each call costs around USD 7 to the company.
Users that could go through the flow and took the car to one of Kavak´s hub wanted to talk to the mechanic because they didn´t feel they could report the problem properly.
Also users got stuck in one particular screen where they could upload media evidence about the car problem and they thought Kavak Customer service would reply chat-like;
Last but not least, we had no data such as completion rate, drop off, average time to match these evidences;
We should think about a solution that doesn´t involve changing the logics for Warranty State Machine.
GOALS
The goal was to understand these pain points and provide a better experience in-app and at Kavak Hub.
Myself together with the research team started investigating the client perception of the warranty in app process in a qualitative way since as forementioned we had no metrics to back up our hyphotesis.
The Process
Myself together with product manager decided to adopt the double diamond to help us to research, understand and find hypothesis due the lack of data we had regarding the warranty process.
Trackling the problem
To understand the problems users were having and reporting to our costumer relations teams four stages were planned.
Running a usability test with Kavak customers using the already in production version;
Analyze the heuristics of this same version;
Collect user comments in social media or formal web-sites like brazilian Reclama Aqui, which is a customer service platform where you can report problems you´re having with a product or service and give the space to the company reply and help;
Interview users that had already used Kavak Warranty and understand their perception about the post sale part of the flow.
Heuristics
Based only on the heuristics, we could point out many flaws on the design in production.
Overwhelming amount information with no connection between them; the two selection groups in the first screen aren´t connected between them when the user wants to report a car problem
Different UI patterns, icon buttons, text buttons, radio selection, dropdown;
Chat format (6th screen) when the user could leave comments, audio and video regarding the car problem they are experiencing left user awaiting for a reply from Kavak team that would happen;
UX testing
Out objectives with this test are:
Intended impact
• Test end to end WSM flow (from home to congrats page)
• Understand user pain points throughout the process and decrease learning curve
• Validate mental model with user when reporting car mechanical problems
• Understand the different levels of UI problems
• Define solution problems
We did both moderated (6 people) and unmoderated (5 people) testings.
The task given was:
Your driving your car when you feel that you´re having problems braking your car properly and you going to report this using your Kavak Warranty.
Some insights from UX testing
User interview
We felt that we have not enough data from the time when the user books to an appointment to take the car to repairment until the moment they take the car back from one of the Kavak´s hub.
Due to the lack of information, we decided to use this technique that could provide us general information related with feelings, attitudes and beliefs. This could give us hints to know where we are failing in our process.
We decided to make a qualitative research, interviewing 11 users in one week:
7 users that had used their warranty more than once and got their problem solved
4 users that had used their warranty once and got their problem solved
At first we wanted to talk with 14 users but due to timetable reasons we couldn’t reach the initial amount. In qualitative research, the sample size is determined by the point at which saturation is reached. After a certain number of interviews, there are diminishing returns — little new information is learned about the topic of study. This is the point where we reach that point of saturation.
Research Goals
To know about the opinions and feelings of our warranty users
To confirm our hypothesis about the user’s main pain points
To establish baselines for our knowledge about users
As we had never spoken with our users, we hadn’t had feedback of what was their opinion or which were their feelings related with the use of their warranty.
We developed some hypotheses and solutions that had been validated to an extent so we needed hints to know if we were in a good or a bad path.
Related with the first goal, we needed to define a starting point for the research and to compare this results in the future.
Research insights
We mapped all the insights and comments from the interviews in Miro and then consolidated them into two groups and we also could notice that we have two personas more evident between Kavak’s users.
Our perception after the interviews
When we finished this round of investigation we reach the most commented subjects
User when reporting a problem take one step at a time
User being able to report more than one problem
Upload audio and media in a format that doesn´t look like a chat
An accurate ETA from our mechanic team
A detailed report on what was repaired in the car, auto parts serial number.
Ideation
Next step was bringing these findings to a workshop with the stakeholders, product team, designers, developers and operations.
This is meant to have every team involved in this experience in the same page; Discussing ideas and probable solutions to validate again with users;
Also I wanted to run this work shop because nobody in the team had been part of an ideation process before and I saw that as an opportunity to build bridges between design and other teams and roles.
You can see the full miro board here <-
Exemple of one of the ideas from one of our participants
Approaching a solution
To work in this MVP due to the amount of insights I worked with our squad PM and developers to understand what we could do first and be able to track metrics.
We decided to used the design system components as they were already clear for using and work on:
- Reporting more than one problem even that´s one at a time
- Change the overall experience of reporting a problem, concentrating the user to answer one question at a time
- Upgrade the media, comment section
- ETAs from every repairment stage
Check the prototype here
