At Lance, a neobank for freelancers, I was the sole product designer. Lance Checkout let freelancers send clients a payment link and get paid by card. Once it launched, the next gap was obvious: users still had to leave Lance to create and manage their invoices.
The opportunity
Most users relied on external accounting software to issue invoices. Bringing invoice creation and tracking into Lance would let them send invoices with embedded payment links, close the gap between billing and getting paid, and keep more of their financial workflow in one place.
Research and scope
I benchmarked neobanks including Revolut and Lili, then looked beyond mobile banking to products such as QuickBooks, Xero, and Square. Our customers already used some of them, which made their patterns a useful starting point.
The research raised more questions than it answered, and we did not have a dedicated product manager. I stepped into the gap, helped define the scope, and worked with the team to prioritize a focused first version.
We identified three assumptions to test:
1. Most invoices contain two to four items.
2. Freelancers usually apply the same payment terms across clients.
3. Users need a way to mark invoices as paid.
User flows
We focused on the primary flow: creating and sending an invoice. That flow included smaller but essential tasks such as adding a client and setting payment terms. After several rounds of iteration, the wireframes were ready to test.
Usability testing
Before handing a feature of this size to engineering, I wanted to test its usability and challenge our assumptions. We ran a remote Maze study with 12 members of the Lance research group I had previously assembled.
The study supported all three assumptions. Eighty percent of participants described the tasks as very easy, with an average usability score of 9.1 out of 10.
Outcome and reflection
Lance Checkout usage increased 113% in one month. Good result, but not the business miracle we expected. Absolute usage remained below expectations, and ARR barely moved.
We validated usability, but not enough demand. If I did it again, I’d test the core assumptions with behavioral or quantitative research and define success metrics before building - not after launch.
From a personal perspective, the project made the value of usability testing very concrete. Participants exposed issues, ideas, and opportunities the team had not identified on its own - and the process was genuinely fun to run.