top of page

EarlyPay 2.0

Creative freelancers can wait up to 90 days to get paid by their clients. Lumanu has a feature to pay creators early, aptly dubbed EarlyPay, but they weren’t returning after their first experience with the feature.

How can we optimize EarlyPay to increase
repeat usage?

Methods

Surveys
Interviews
Data analysis
Wireframing

My role

Product designer

UX researcher

Context

Lumanu is a finance and invoicing app moving money in the creator economy. This project took 3 weeks.

Collaborators

Product manager and tech lead for mobile pod

Customer experience specialist

The problem

Creative professionals often have to send invoices to clients that will get paid out in 30, 60, or even 90 days. When a creator invoices through Lumanu, they can take advantage of a feature called EarlyPay where Lumanu pays them within days of sending the invoice, rather than having them wait the full invoice term.

 

Users raved about EarlyPay, but there was one problem-- according to usage data, only 32% of creators who got EarlyPay once in the last 3 months received it again on a subsequent invoice.

EarlyPay usage funnel

Bar graph showing a two step funnel. Bar 1 is at 100% and represents all creators who received payment via EarlyPay once. The second bar shows that only 32.4% of the group from bar 1 received EarlyPay on a second invoice.

The team had already identified certain improvements to the existing EarlyPay process that would increase usability– namely, allowing creators to request EarlyPay straight from the app. However, we didn’t know whether the existing EarlyPay process was indeed the root cause of poor repeat usage.

Current EarlyPay process

Image of a timeline of the EarlyPay process. When a user creates invoice in Lumanu, the Lumanu PayOps manually verifies if the invoice is eligible to get paid early. If it is eligible, PayOps sends an EarlyPay offer over text. If the user accepts, PayOps reaches out to the invoice recipient to validate the user’s work. If the work is validated, PayOps subtracts the 2.9% fee and pays the user early. Creators will now be able to request EarlyPay in the app instead of waiting for an offer.

Diving deeper

I partnered with one of our customer success specialists, Haley, to investigate why 67.6% of EarlyPay users weren’t receiving EarlyPay a second time. We created a 2-part research plan to uncover different facets of the problem.

METHOD 1

Unmoderated survey

We want to understand why users have accepted or declined EarlyPay after already having accepted it once.

Implementation: We sent a 9-question survey to the cohort of users who only accepted EarlyPay once.

METHOD 2

Remote interviews

We want to understand the context behind a user’s decision to accept or decline EarlyPay, and how their first impression of the feature shapes their experience.

Implementation: We spoke to 8 creators who took our survey to dive deeper into their survey responses.

Findings (and a plot twist 🤔)

After two weeks of research, I set about analyzing our data using visualizations and qualitative coding. This resulted in 3 primary findings that would influence our brainstorming work.

FINDING 1

The primary factor stopping users from requesting EarlyPay a second time is the 2.9% fee.

Creators mentioned that for invoices with smaller amounts or shorter due dates, the fee wasn’t actually worth it.

FINDING 2

Users want insight into the EarlyPay process before and after requesting EarlyPay.

7/8 of our interviewees were surprised when EarlyPay took as long as it did, and 6/8 indicated that they wanted more communication about the status of their EarlyPay request during the process.

FINDING 3

The secondary reason users aren’t accepting EarlyPay a second time is because they aren’t getting EarlyPay offers from the Lumanu team.

Wait... what?! – was my reaction when we saw this in the data. I segmented our original funnel data further and noticed something new–  the biggest drop-off happened between receiving EarlyPay on a one invoice, and then sending a second invoice. If a creator doesn’t send an invoice, they can’t get an EarlyPay offer.

SC 1.png
A screenshot of a Miro board showing sticky notes corresponding to survey answeres. There are two notes about survey results, which are displayed as a bar graph.

Prioritizing interventions

Our findings suggested a few approaches we could take to solve our repeat usage problem, in and out of the app. After some brainstorming with Haley, I presented the proposed interventions to our product manager and Payments team. We discussed the time and effort required for each one and ultimately decided to incorporate 6 of them – highlighted in green in the chart below – into our new EarlyPay designs.

APPROACH 1

Make the EarlyPay fee seem “worth it” on invoices that had smaller amounts or shorter due dates.

APPROACH 2

Increase education about EarlyPay before, during, and after creators go through the process.

APPROACH 3

Make the internal EarlyPay process less manual and more efficient for our Payments team.

Four quadrant graph where the Y axis charts "More impact" to "Less impact" (top to bottom). The X axis charts "More effort" to "Less effort" (right to left).
Four green sticky notes in the “More impact, less effort” quadrant. The sticky notes read - Approach 1: in-app tips to add EP fees into invoices – clients pay for you. Approach 2: feature onboarding before first EP usage. Approach 2: display status of EarlyPay request in-app. Approach 3: time limit on EarlyPay approval/rejection from PayOps team.
Three gray sticky notes in the “More effort, less impact” quadrant. The sticky notes read - Approach 1: Free trial of first EarlyPay to decrease time to activation. Approach 1: Push notify to request EP on higher/longer invoices. Approach 2: Invoice timeline that records all invoice status changes in-app
More effort, more impact
Three sticky notes in the “More effort, less impact” quadrant. Two green sticky notes read - Approach 2: provide reasoning behind EP rejections. Approach 3: automate comms from Payments team to users. One gray sticky note reads - A3. create in-app shortcuts to request EP quickly.

Bringing ideas to life

I started my design process by building on the sketches I created during our brainstorming session. Over the period of a week and a half, I iterated on the screens and flow with critique from the design team and frequent check-ins with my PM and engineering lead.

5 images showing the design progression of the Request EarlyPay screen in mobile. The first image is hand-drawn sketches in a notebook. The second image is an Invoice Details screen with a horizontal timeline at the top showing the invoice progression and an electric green banner under the invoice amount. It says “Get EarlyPay: We’ll pay you $4,855.00 now (2.9 fee%).” The third image is an Invoice Details screen with a vertical invoice timeline and two buttons placed horizontally in the upper area. One button says “EarlyPay” and the other says “Invoice details”. The fourth image is an Invoice Details page with a vertical timeline and two full-width buttons under the invoice amount. One button reads “Request EarlyPay”, and other reads “Invoice details”. The final image shows an electric green banner that reads “Get EarlyPay: We’ll pay you $4,855.00 now (2.9% fee)” under the invoice title and amount. There is no timeline.

Brainstorming

V1, V2, + V3 - Timeline UI explorations which got cut due to scope

Final version

This collaborative working period resulted in a new, self-service flow where creators can request EarlyPay and view their request status in app. Although originally out of scope due to timeline, I was able to advocate for a light feature onboarding flow so that creators would know what to expect when using EarlyPay for the first time. I also worked with our PayOps team to streamline text and email comms related to EarlyPay and establish a 3-day maximum EarlyPay processing limit.

SELF-SERVICE EARLYPAY

Creators can request EarlyPay on any invoice sent from Lumanu, and check on the status of their EarlyPay request in-app. Because the primary goal for this screen was to draw attention to the CTA, I used brand colors and placement on the screen to make the "Request EarlyPay" banner stand out.

A five screen sequence showing the Request EarlyPay flow on mobile. First, a user selects a sent invoice from a list of their invoices on the Get Paid tab of the Lumanu app. The user is taken to an invoice details screen where they can request EarlyPay by tapping on the electric green banner that says “Get EarlyPay: We’ll pay you $4,855.00 now (2.9% fee)” under the invoice title and amount. The user is taken to a screen which shows instructions, the original invoice amount, the EarlyPay fee, and payout amount. The instructions tell the user that Lumanu will reach out to the invoice recipient, and that the user will hear back about their request in 3 days. Once a user requests EarlyPay, the banner turns gray and shows the new EarlyPay request status, which reads “EarlyPay pending”. When a user clicks on the status, they are taken to a screen that shows the original invoice amount, EarlyPay fee, and final payout amount.

EARLYPAY STATUSES IN-APP

Before the re-design, creators felt that they were left in the dark about the status of their EarlyPay request until PayOps reached out to them manually. Now, creators are notifed as soon as their request status changes.

I also worked with our PayOps team to create a 3-day processing time limit as creators mentioned waiting on EarlyPay approval for weeks or sometimes even a month.

Two mobile screens, the first showing the EarlyPay Accepted status. There is a light green banner below the invoice name and amount that says “You got paid 28 days early!”. When a user clicks on the banner, they are taken to the second screen that shows the original invoice amount, EarlyPay fee, and final payout amount.
Two mobile screens, the first showing the EarlyPay declined status. There is a white banner below the invoice name and amount that says “EarlyPay declined”. When a user clicks on the banner, they are taken to the second screen that shows the original invoice amount, EarlyPay fee, and what the final payout would have been had EarlyPay been approved.

FEATURE ONBOARDING and FEE REDUCTION

The majority of creators we spoke to wanted a more accurate understanding of EarlyPay before using it for the first time. I created an onboarding flow which also included a tip on how to reduce fees. As discussed above, fees were the top reason creators weren’t coming back to EarlyPay. Although not originally included in scope, I was able to work with our PM and engineers to add the flow into our timeline.

EarlyPay onboarding.png

Outcomes

6 weeks post-launch, we could see a marked improvement in EarlyPay retention and revenue. Within 6 weeks, we had an almost 41% retention rate compared to the 32% over 3 months that we started with.

$51.8K

revenue generated in 6 weeks of launch

↑ 150.46% increase

2.3 days

average amount of time from EP request to payout

↓ 67% decrease

318

EarlyPay requests paid out in 6 weeks of launch

↑ 126.23% increase

40.9%

retention rate in 6 weeks
of launch

↑ 26.2% increase

But wait! What about the plot twist?

Earlier in our research, we found out that the second most common reason creators weren’t coming back to EarlyPay was because they weren’t sending more invoices. But Rishma, you didn’t include any of that work in this case study!

Worry not. Luckily, my team was concurrently working on building out major invoicing improvements based on prioritized user feedback from another study. Check them out by sending your next invoice on the Lumanu app!

bottom of page