Clarity
DailyPay is a fintech startup that grants people access to their earned wages before payday.
Sector
FinTech
My Role
Product Designer
Team Members
1 Product Manager, 4 Engineers, 3 Stakeholders
Project Timeline
8 months
Overview
DailyPay's core product offering is allowing users to withdraw money from their next paycheck before payday. As the product team reviewed user habits via Fullstory, customer calls with the support team, and amplitude, it was clear that users were not using the app to make transfers but instead to ensure their earnings are updated by their employer. Something needed to be done to cater to the majority of daily users that were using the app this way.
Key Objectives
Provide a feature that gives users a comprehensive view of the money they make after every shift, the amount that is held for withholding, and the amount they can transfer and or save.
Research
Goal
Get an understanding of:
1. How users are using the DailyPay app?
2. What questions do users have about the benefit in relation to their pay?
3. What other product offerings can DailyPay offer to help these users?
Exploration
1. Users were spending less than 5 seconds on the app
2. Users were just opening the app, scrolling down to the earnings card and then exiting
3. Users were not tapping on anything
.png){kind=small}
1. The average transferred amount was $0.00 and $99.00
2. The average time visited the app was 4 times a week
Customer Calls with Customer Support
1. Users were very confused on how their DailyPay Balance is updated
2. Due to lack of transparency, users were often angry when their balance is not updated
3. Users would often go to their HR department to ask DailyPay related questions
"I really only use DailyPay to make sure my employer paid me! But when I first used the product I could not understand why my full pay was not reflected in my DailyPay Balance."
-User
Backend Development Team
I meet with the backend development team to view the dataset tables of incoming information partners were providing. I wanted to see if there were any valuable information I can rely on to users in my solution.
*due to legal reasons I can not provide that information.
SWOT ANALYSIS
To get a better understanding of the current product I conducted SWOT analysis of the current feature.
Strength
- There is traction with the feature
- DailyPay has all of the incoming data to provide users with a holistic view of their earnings
Weakness
- Because of a lack of information users could not tell how DailyPay works
- Users typically had to ask someone who was familiar with the product to understand it.
- Users do not understand how a pay period works
Opportunity
- Provide users with a comprehensive dashboard that outlines their balance
- Lessen the amount of call to support with balance related questions
Threat
- A raise in drop-off rates
- Negative reviews from confused users
Questions/Takeaways from SWOT ANALYSIS
1. Are these weaknesses present anywhere else in the product?
2. What is all of the information that a user needs to have to fully understand their balance?
3. I should talk to the partner portal team to understand how employers track and share employe's earnings with DailyPay?
Key Findings
Notable Trends
1. All of the actions users were doing took place on the homepage
2. If users did not find the answer they would call support or ask their management
Needs
1. A detailed panel that explained user earnings
2. A easier way to explain the concept of DailyPay
Pains
1. A real time update of balance updates
2. Could not understand how the percentage for withholdings was calculated
Desires
1. A real time update of balance updates
2. A way to send paycheck feedback
Hypothesis
I believe that users are not taking advantage of the pay benefit because they do not understand how it works. There is no explanation on how a DailyPay balance is calculated leaving users confused and unwilling to make transfers because they are afraid it is going to affect their paycheck.
Regrouping with the team!
After researching, I went back to the team and the stakeholders to present my findings and share my hypothesis. The objective of this was to make sure everyone was aligned with the OKRs, projects goals, and business needs.
My goals as a designer
1. Data Visualization: After research, it is apparent that some elements of data visualization should appear. Adding more data visualization would give me the opportunity to grow as a product designer.
2. User needs are being translated into a mobile-friendly user interface. This feature needs to be as transparent to the user as possible.
3. Start to establish and define design principles.
Business goals that aligned with design
1. Raise the retention rate
2. Reduce the number of calls that come into customer support about earnings
3. Provide an added benefit for future partners
"This feature needs to be able to provide added value to the user and the partner."
-Stakeholder
Technical goals that aligned with design
1. Create a product that adds value in the user's life
2. Have an alignment, so the live feature looks like what was designed
UI Architecture
After aligning with the team, it is time to condense all of the research and start to frame the solution and the UI.
How might we?
I wanted to start with a how might we statement to have a short sentence that I can refer to during this process. This will help me and the team stay on track with what is best for the user.
"How might we use all of the incoming data from partners to create a detailed, comprehensive, and holistic view of users' earnings?"
User Flow
First I identified what elements need to be there to complete my goals.
User Need
My Thoughts
"Is DailyPay going to affect my pay in any way?"
Users need to visually see the evolution of their paycheck.
"Why was the money that I transferred coming out of my next paycheck and not the current one?"
Users were not understanding how a pay period worked.
"I could not understand why my full pay was not reflected in my DailyPay Balance."
Users were not understanding how the DailyPay Balance is calculated.
UI Element
Paycheck View: A way for users to get details on their paycheck
Pay Period View: An explanation of where the user is in the pay period and what is to come next
Help: Customizable DailyPay Balance and a universal explanation
Now that I have identified the element I can view the user flow chart of the entire and identify where these elements can fit.
Wireframes
I first drafted low-fidelity sketches, after doing on-paper sketches.
A statements page
DailyPay Balance breakdown
A transaction explained
Paycheck tracker
Then to get feedback from the Product Manager and the engineering lead, I created mid-fidelity sketches. This helped me narrow down a few of the ideas I wanted to explore based on my research.
"I really like the visual indication when something has gone up or gone down. This card feels too cluttered."
- PM
"You have to think about what happens in each section when we do not get the data back from a partner in a timely manner."
- PM
"How would this display on a smaller screen size?"
- Engineer
"Let's see how users react to the concept of "money in" and "money out" with the negative sign in front of it?"
-PM
"The backend is not set up to support the "punch card" feature."
-Engineer
Takeaway/Next Steps:
1. Tone of copy: A collab session with the PM, and marketing to align with the phrasing of key financial terms would be beneficial.
2. Information Architecture: There is too much information that needs to be explained to the user. All of that information can not fit on 1 card that lives on the dashboard.
3. Tradeoff: For the sake of time, I will have to save the "punch card" for another iteration version of this feature.
I wanted to take this a step further, so I created a high-fidelity version of the Clarity card to test.
"There is too much happening on this card. Since this is new, does that mean there are old activities? What makes up these timeframes?"
-Test Participant
"I am unsure what the bar is? Am I supposed to move it? Does it mean I haven't earned all of the money, because it is not fully closed"
-Test Participant
The Test
Participants: 5 individuals
Questions
1. How much did you transfer on August 18th?
2. Can you state the amount of money you took from your last paycheck?
3. If you want to find transactions from August 17, what would you do?
*An explanation of the feature is provided*
4. Can you explain what the numbers at the top are?
5. Do you feel that there is anything missing from this card that would have help you understand the DailyPay Balance and your paycheck?
Takeaway:
1. Users wanted more information about each activity and their paychecks.
2. The data visualization was not clear to all 5 users.
3. Participants did not know what paychecks had to do with activities
After reviewing the feedback from the test I realized that there need to be 2 separate cards for the balance summary and the paycheck. Also in addition to the cards there need to be more details on them both.
High fidelity Sketches
"I brought a lot of the focus back to the DailyPay Balance. I wanted this card to be simple so users can understand how it is calculated in a faster way."
"Instead of a bar like I had created in the previous version, I decided to use a circle. I came to the realization that it resembled a UI loading bar and it was causing more confusion than benefit."
"I wanted to provide users with more explanation to things that customer support would get calls about."
"This format allowed room for the feature to grow and provide more information to users."
"I also decided to introduce UI chips on the platform. This can help provide a status to things that are in progress."
The Aftermath
Once I was done designing the solution I met with the respective teams to make sure they were aware of the solution.
The Handoff
The handoff process is one of my favorite tasks in my process. It allows me to regroup with the team(s), share my insights, and create material that would help the rest of the team.
Stakeholders, Data Team and Product Manager
During the design process, the PM and I created a set of KPIs to track and help determine the success of this feature.
Non-Product Teams at DailyPay and the Engineering team
Another thing I like to create and store in the Figma file is a "How To" document. This allows anyone in the company to read what this feature is about. My main use case for this document was for someone on the customer support team to be better equipped with the tools they need to explain the feature to a user. This document was also really helpful for engineering because I detailed all of the use cases and the user flow for each one, the various states of buttons and chips and I also detailed out all of the foreseeable error states.
"This document cut the product and customer support monthly meeting in half! Everyone was able to refer to the document and I did not have to spend time explaining each function of the feature. This is great!"
- Director of Product Management
Users
While thinking about the feature holistically, I thought there needs to be a way for users to be aware of this new feature. Since Clarity has 3 subsets (the dashboard card, the balance summary, and the paycheck tracker) there needs to be a way to familiarize the user with all 3 areas. So while the engineers were working on development I created a pendo for launch that would appear once a user opens the app. This pendo would take the user through a quick onboarding of the feature. I also add a 1 question survey at the end to get an understanding if this pendo was an adequate way to explain the feature. The feedback from this would help me determine how new features are presented in the app.
Results
Once the feature went live I started to watch all of the incoming data to determine if this solution was successful or not.
1. Newer users clicked the "i" icon more frequently than an older user
2. Users were tapping on the money values on the dashboard card
3. Users interact with the balance increase details more than any other activity
4. The date chips did not translate well on smaller screen sizes and on android phones were the user has their font size increased
1. The feature got a lot of traction right before the user's payday.
2. There is more interaction with the feature through the dashboard card vs. the main menu
3. Retention on the homepage raised by 70%
Customer Calls with Customer Support
1. DailyPay Balance related questions were reduced by 30%.
My goals as a designer
1. Data Visualization: After research, it is apparent that some elements of data visualization should appear. Adding more data visualization would give me the opportunity to grow as a product designer.
2. User needs are being translated into a mobile-friendly user interface. This feature needs to be as transparent to the user as possible.
3. Start to establish and define design principles.
Business goals that aligned with design
1. Raise the retention rate
2. Reduce the number of calls that come into customer support about earnings
3. Provide an added benefit for future partners
"The overall retention rate was raised by 25%, and the number of calls was reduced by 30%."
Technical goals that aligned with design
1. Create a product that adds value in the user's life
2. Have an alignment, so the live feature looks like what was designed
Hypothesis
"I believe that users are not taking advantage of the pay benefit because they do not understand how it works. There is no explanation on how a DailyPay balance is calculated leaving users confused and unwilling to make transfers because they are afraid it is going to affect their paycheck."
So was my hypothesis above correct? Well, it only covered half of the problem. I realize there is a bigger picture that needs to be explained in this feature. Users do not fully understand the pay period system which in turn would confuse them when trying to understand an on-demand pay system.
Next Steps
With all of the new insights, I started to brainstorm what V2 can be for Clarity.
1. Notifications: It is clear that users are coming back in a timely manner. It can be an added benefit if push notifications were utilized when an activity occurs. This will be customized by the user based on their needs.
2. Other use cases: Everyone's pay is different which creates a lot of different use cases for Clarity. V1 was only able to address the main use case. In V2 there needs to be an in-depth looking into the others and address those gaps.
3. This is the first time that new elements are added to the app since it went live 6 years. There needs to be an alignment between design and engineering to create a process for new elements.