AI Search Builder

Crunchbase gives users access to a plethora of valuable data – financial, investment, and growth insights for over 3,000,000 companies, 280,000 investors, and more – but archaic filtering and search patterns make this data hard to sift through.

How can we incorporate natural language processing to make searching on Crunchbase more approachable for users?

Methods

Usability testing

Data analysis
Wireframing

Beta testing

Context

Crunchbase is a company data platform for salespeople, investors, and CEOs to find and close business.

My role

Product designer

UX researcher

Collaborators

Product manager and tech lead

UX researcher

The problem

Crunchbase houses tons of valuable data - financial, investment, and growth insights for over 3,000,000 companies, 280,000 investors, and more - but requires users to sift through over 100 filters on two different interfaces to find the data they're looking for.

For years, users told us through interviews and CX tickets that they had difficulty identifying which filters they would need, finding those filters, and updating them once applied. The entire experience was clunky and in desperate need of a refresh.

Simple filters

Complex filters

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.

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

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.

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!