Flex is a fintech company that began with a mission to improve the rent payment experience for people who are financially constrained. Their core product is a service that allows customers to split their monthly rent into smaller payments scheduled over the course of the month. So for people who need to put an entire paycheck toward their rent, the service evens out their cash flow, prevents late payment (and associated fees), and even establishes credit history.
I was conducting generative qualitative research centered on how people manage their cash throughout a month. Given that rent tends to be both the biggest expense and the most important expense for most people, I learned about some interesting strategies that people use to try and ensure they can pay their rent in full and on time. One such strategy was reported by multiple participants:
Keeping a separate checking account
for which rent is the only intended spending.
For people who used this strategy, they would either direct deposit or manually deposit some percentage of their paychecks into this designated account. They made an informal agreement with themselves that the funds in this account were to be used only for rent and not for other spending. This arrangement prevented overspending in other parts of their budget.
Separately, Flex was dealing with compliance requirements dictated by our payment processors, Stripe and Visa. In short, these requirements dictated that Flex couldn't capture customer funds until services had been rendered. This meant that if customers choose to make a payment early, those funds need to be available for withdrawal by the customer until Flex fullfilled its service obligations. Because Flex had no way of making funds withdrawable at the time, early payment wasn't possible.
I wanted to learn more about the insight regarding separate checking accounts, so I conducted some additional qualitative research. I asked questions like:
I also looked at other apps that have some sort of cash management feature that acts like a specialized checking account:
Paypal
Cash App
Robinhood
Uber
For these examples, it's worth highlighting that customers can make deposits and withdrawals, but the funds can only be spent on the app's services (e.g. Robinhood stock purchases and Uber rides.)
While we already had established cash management as the primary goal, there are infinite ways of incoporating that into our product. I pulled in some of my favorite collaborators and we came up with several approaches.
Recurring deposits
based on payday
Manual deposits
with weekly calendar
All payments presented with a progress bar
Deposit as primary action in a summary
There were definitely some patterns emerging already. A few key concepts kept appearing repeatedly:
Developing an understanding of when customers get paid and syncing Flex payments to that schedule
Reflecting any cash holdings as progress toward the next payment amount
Incorporating non-rent costs into a budget, and providing recommendations on how to use Flex to best control cash flow
However, these concepts all felt like improvements to an MVP solution that focused on the initial insight of setting cash aside. We didn't need to know the customer's pay schedule or spending habits in order to provide a pathway for the behavior of saving ahead.
We did need to resolve some questions that emerged regarding how this behavior fit into the product experience. In fact, the whole notion of early partial rent payments conflicted with the product construct.
I built a simple prototype and conducted some user testing. The big question we needed input on was whether customers would understand that their stored funds would be automatically applied to their next payment. This question had further complexity because most payments were initiated by Flex automatically on a scheduled date.
There was a lot of urgency in releasing an MVP just to satisfy the payment processing requirements for early payment, so the initial visual design had to be done quickly. One of the most impactful screens, which I put together in a few minutes, was this "how it works" summary.
Explaining the new feature
I had to push for some augmentations to existing screens to integrate "Flex Funds" in a comprehensible way. But since the majority of this feature comprised net new screens, I had an opportunity to evolve aspects of the visual language. This project became a big source of additions to our design system.
At first, certain aspects of the stored funds experience were scaled back in the interest of unblocking the payment processor requirements, but the majority have since shipped. The most impactful goal for both customers and the business was enabling save-ahead behavior and early payments. Adoption of this feature was on par with our expectations, but there was a big lesson, which wasn't apparent in the event data...
Customer review from the Apple App Store
While the problem we had set out to solve with this feature was important, our solution contributed to a much larger customer need around payment flexibility. We'd been operating under the assumption that automating as much of the experience as possible was best for all parties. However, this feature contradicted that assumption, and it motivated us to address other gaps in the manual vs. automated spectrum. The largest product improvement to grow out of this insight, is a product variant that allows for episodic usage of the service. And this variant is already allowing Flex to access an entirely new customer segment.
Other Projects
AwayWeb homepage
Minibar DeliveryE-Commerce mobile app
KitchensurfingFood service mobile app
PocketMobile app onboarding
Thirty LabsBeta projects
Telecast (Betaworks)Video mobile app
Heartbreaker WallInteractive installation