Lance
How we created & validated an invoice tracker, and closed the client-payment loophole for our freelancers.
Early 2022 • Product designer • Mobile app design, prototyping, wireframe -> handoff, Usability testing
Early 2022 • Product designer • Mobile app design, prototyping, wireframe -> handoff, Usability testing
I was working at Lance – a neobank for freelancers – as a solo-designer. One of Lance’s popular features, called ‘Lance Checkout’, allowed freelancers to send direct payment links to clients, and get paid via credit card. When we finally launched it, the next opportunity was right around the corner.
Most of our users used external accounting softwares to issue their invoices. ‘Lance Checkout’ was popular, yet we thought the ability to create & track invoices will give us an advantage. Besides being a long requested feature, it would allow users to issue & send invoices with direct payment links within them – thereby closing the payment loophole many freelancers have with their clients, and consolidate more of their activity into Lance.
Starting the research, I mainly used familiar neobanks – such as Revolut & Lili – as a benchmarking reference, but also looked beyond neobank and mobile apps to discover diverse opportunities in platform such as Quickbooks, Xero, and Square. I knew our customers were using some of those platforms already, so it would probably be a good starting point.
Research has brought a lot of questions and scoping was needed, but we lacked of a dedicated PM on the team. It ended up with me taking the responsibility, which I think I handled decently. Few iterations after, we came up with some basic assumptions, and prioritized our first version's features.
As I mentioned, I had some questions left that ended up in assumptions that we later put into test:
1. People usually issue 2-4 items per invoice.
2. People usually give the same payment term to all their clients.
3. Marking paid invoice is mandatory to our users.
We were happy from what we had, so from this point on we focused on the main user-flow – issuing & sending a new invoice – which included several small flows such as ‘Adding a client’, and ‘Setting a payment term’.
We iterated on these wireframes & flows for a few days, and went on to...
Before delivering such a big feature to development, I wanted to be more certain about usability, as well as validate or deprive the assumptions we laid earlier. So, using Maze we took it into a remote usability study with our research group of Lance users that I assembled previously.
Usability tests had great results. 12 users took the test, and while they validated all the assumptions we had, 80% of them said the tasks were really easy to complete, with average usability score of 9.1.
I think the process we had was quick and efficient. Results were good - Lance Checkout usage was more than doubled! It grow by 113% within a month - but it was still on lower numbers than expected, and didn’t help us increase our ARR significantly as expected.
In retrospect, I would have changed a few things. First, I probably should have validated our assumptions using a different method than a qualitative survey. Second, we probably should have come up with a different way to measure the feature success, which we never addressed beyond the Checkout usage.
Yet from my perspective, I discovered how essential usability tests can be to confront assumptions and validate a feature’s design, some responses taught me a lot, or suggested features or improvements that we couldn’t come up with by ourselves. Most importantly, I really enjoyed this entire process.