Possible Finance is a mission-driven series B fintech startup that provides small-dollar loans via a mobile app.

These loans provide much needed credit to an underserved segment of the American population. Proprietary machine-learning technology allows Possible to sustainably deliver these consumer-friendly loans without the risk traditionally associated with a short-term installment loan.

The app is easy to use… and I seriously can’t thank them enough for the service they provide and the care they show customers. It’s like borrowing money from a good friend that increases your credit score!

— NellyVille1027, App Store

I worked at Possible Finance as a Product Designer for one year. During the final 4 months of that year I was the only designer at the company, and was responsible for all brand, marketing, and mobile app designs, as well as the implementation of a custom design system and the shipping of several features.

Below I will explain how I re-shaped the Possible mobile app from a linear single-purpose application to a modular and scalable financial wellness platform.

Purpose —

With the loan product doing well, leadership wanted to expand and add features that would:

  • Keep users coming back to app more often than just the loan product does.

  • Potentially open up a new revenue stream.

  • Continue the mission of helping financially under-served Americans.


Overdraft Fees —

According to MarketWatch, consumers paid $34 Billion in overdraft fees to banks in 2017.

By performing dozens of interviews with existing customers I learned that bank fees are an epidemic that disproportionately affects the customers that need Possible’s loans. We also investigated several companies who were already in the business of fighting bank fees, but none were doing so by helping the customer understand the behaviors that lead to fees occurring.

We decided to build a feature that would show a customer how much money they were paying in fees, when the fees were occurring, why the fees occurred, how their habits have changed over time, and what they could do about it.

We performed a trial run of requesting fee refunds on behalf of customers. This proved successful, and could become a new revenue stream, but due to the COVID-19 pandemic the idea was shelved until a later date. Below is a video created by a participant in this trial.

Information Architecture —

From the beginning, the Possible mobile app had been built as a single linear flow to apply for, receive, and pay back a loan. As the company dreamed of new endeavors, we realized that massive changes to the app’s underlying structure would be necessary. I decided that a hub-and-spoke model, with multiple flows exiting and returning to a central dashboard, would best solve our problem.

Most importantly, the bank linking flow (done via Plaid) needed to be extracted from the loan application flow and inserted into the onboarding flow. Having access to bank transaction data is critical to the function of nearly every feature.

I collaborated with each function in the company to audit every screen in the app. I was able to identify visual improvements that could be made, screens that could be removed, screens that could be added to improve overall UX, and screens that could be moved to a different location.

This redesign of the app’s information architecture was necessary to allow the product to expand, and built the foundation for all new features to be added later on. These changes did not result in any drop in conversion or loan application rates.

Dashboard & Components —

Pictured below is the old “home” screen, which showed information about a user’s current loan. It also had a hamburger menu behind which was hidden multiple features, some useful and some not. Overall, this system was not effective for either a user or the business.

I proposed a card model. This would allow the dashboard to host as many features as needed and consolidate all information regarding the loan to one card, reducing confusion with other features. It would also allow the secondary information to be more logically organized and accessible.

I developed a card component that would meet the needs of any card to be used on the dashboard or account screen, as well as handling any state of the loan card. Consolidating the loan card was a difficult task because loan information had been spread out throughout the app and displayed in multiple different formats. In the end, I identified 28 different “loan states” and defined the card component for each.


My original idea for the dashboard and account screen was to place both on the same plane, allowing swiping horizontally between the two. Unfortunately, late in the development process it was decided that this was not in scope for the project, and I had to change the behavior back to the original menu behavior. I believe this caused the card model to be less effective because the account screen now seems to hover above the dashboard, rather than sitting next to it on the same plane.

At the same time as this project, we were also implementing a new custom design system and component library. This limited the colors, styles, and UI elements I had access to while designing the new UI. Additionally, there was not even bandwidth to fully redesign some of the cards on the account screen, resulting in a copy and paste of several old components into the new cards.

Intended DesignIntended Design

Intended Design

Actual ResultActual Result

Actual Result

Fee Visualization —

My final solution, which was developed and shipped to all Possible users in Q1 of 2020, helps users keep track of fees being charged by their banks. I achieved this by designing a simple yet powerful interactive visualization.

Early iterations of the fee visualization screen.Early iterations of the fee visualization screen.

Early iterations of the fee visualization screen.

Possible already has access to a user’s bank transaction data because it is used for underwriting loans, so this feature uses the same data to recognize fees and categorize them as either overdraft, maintenance, ATM, or other. Through user testing and research we found these to be the most common and important types of fees.


The bar chart shows the total dollars spent on fees month-by-month with the lower section showing totals in each category. Tapping on a month highlights it and adjusts the data below to show just that month. This allows users to quickly understand the patterns and behaviors that result in fees, as well as how those behaviors trend over time.


Customers we spoke to made it clear that it is important to know which transaction caused a fee, and when it occurred. So we included a details screen for each category which lists the fees by date and shows the transaction that caused it.

I also developed a formula to determine the pixel height of the internal bar representing the percentage of the fee that had been recovered. This would ensure that the internal bar would never exceed the defined padding even if the recovered amount was equal to the charged amount. This, along with extensive redlines referring to components in the design system I helped build, allowed me to communicate the idea to engineering in terms that made immediate sense to them.


View fullsize

A formula I developed to determine pixel height of the inner bar relative to the outer bar.A formula I developed to determine pixel height of the inner bar relative to the outer bar.

A formula I developed to determine pixel height of the inner bar relative to the outer bar.


View fullsize

An example of redlines delivered to engineering.An example of redlines delivered to engineering.

An example of redlines delivered to engineering.