OnePay

A self-initiated design demo, addressing the consumer debt crisis

Project Context

I wanted to create a small design demo unbounded by the constraints of a typical product development pipeline. I also wanted the project to have meaningful context, so I considered how design might improve people's financial situations. Consumer debt in the United States can produce a dangerous cycle of poverty, and the general population is under-educated about the fundamentals of efficient repayment. Without the ability to strategically allocate their repayments, many people are accruing deep deficits that they struggle to repay. Thus, consumer credit card debt became the focus of the project.

I wanted to create a small design demo unbounded by the constraints of a typical product development pipeline. I also wanted the project to have meaningful context, so I considered how design might improve people's financial situations. Consumer debt in the United States can produce a dangerous cycle of poverty, and the general population is under-educated about the fundamentals of efficient repayment. Without the ability to strategically allocate their repayments, many people are accruing deep deficits that they struggle to repay. Thus, consumer credit card debt became the focus of the project.

Task & Constraints

I set about imagining a piece of software that could easily assist people with credit card debt in particular. The initial idea was to simplify credit payment patterns, allowing people to intuitively understand when their bills were due, and how to avoid paying interest. After researching the behavior of those who accrue credit card debt, however, I noticed that my strategy was still too complex. The app needed to boil every variable down to one number: one payment per month. The user makes the payment, and the software decides where to allocate it.

I set about imagining a piece of software that could easily assist people with credit card debt in particular. The initial idea was to simplify credit payment patterns, allowing people to intuitively understand when their bills were due, and how to avoid paying interest. After researching the behavior of those who accrue credit card debt, however, I noticed that my strategy was still too complex. The app needed to boil every variable down to one number: one payment per month. The user makes the payment, and the software decides where to allocate it.

My Role

As a self-initiated design demo, I created every aspect of this project. In keeping with the mandate for simplicity and ease of use, I worked through several iterations. I sketched, designed, and the iteratively simplified the hierarchy, navigation and architecture. Because credit debt can be anxiety inducing, I chose to bring a sense of levity to the experience: using a bright and highly saturated complimentary color scheme, as well as animations with greater bounce easing than would be typical of a financial app. I built the designs in Figma and animated them in After Effects.

As a self-initiated design demo, I created every aspect of this project. In keeping with the mandate for simplicity and ease of use, I worked through several iterations. I sketched, designed, and the iteratively simplified the hierarchy, navigation and architecture. Because credit debt can be anxiety inducing, I chose to bring a sense of levity to the experience: using a bright and highly saturated complimentary color scheme, as well as animations with greater bounce easing than would be typical of a financial app. I built the designs in Figma and animated them in After Effects.

Outcome

The OnePay demo demonstrates that a serious financial tool can also be beautiful and consumer-friendly. If a team were to build this, it would afford many people a path to eliminate their debt burden without needing to calculate tables of data. The concept has precedent, it turns out, as I learned that Seema Amble et.al. wrote about it for Andreessen Horowitz, in “Who Will Build Consumers a Debt Dashboard?” The demo was also an enjoyable design exercise, allowing me to move in more creative directions than would typically be afforded in a production app.

The OnePay demo demonstrates that a serious financial tool can also be beautiful and consumer-friendly. If a team were to build this, it would afford many people a path to eliminate their debt burden without needing to calculate tables of data. The concept has precedent, it turns out, as I learned that Seema Amble et.al. wrote about it for Andreessen Horowitz, in “Who Will Build Consumers a Debt Dashboard?” The demo was also an enjoyable design exercise, allowing me to move in more creative directions than would typically be afforded in a production app.

FUnctional & beautiful

The project demonstrates that a serious financial tool can also be beautiful and consumer-friendly.

The project demonstrates that a serious financial tool can also be beautiful and consumer-friendly.

Project Details

Project Details

Below you will find a detailed breakdown of the OnePay financial tool project, from beginning to end.

Research & Discovery

Our leadership team identified the ideal customer profile as "mass-affluent" – earning $100,000 or more – between ages 25-45, and skewing male (though we marketed to men and women). I also recorded and analyzed the flows of 10 market-adjacent term brokers, with special emphasis on Ethos, Ladder, and PolicyGenius. Additionally, our underwriting partner supplied their API guide, which I integrated into the foundation of the system as a whole.

Our leadership team identified the ideal customer profile as "mass-affluent" – earning $100,000 or more – between ages 25-45, and skewing male (though we marketed to men and women). I also recorded and analyzed the flows of 10 market-adjacent term brokers, with special emphasis on Ethos, Ladder, and PolicyGenius. Additionally, our underwriting partner supplied their API guide, which I integrated into the foundation of the system as a whole.

API Calls

Our partner supplied JSON returns from their API, which fed our system the necessary questions for an IUL application. The design system needed to account for all possible response types (boolean, date, free text input, multi-select, radio, etc.), as well as delays in response times (see below).

Product Vision

"Applied at lunch, covered by midnight"

I summarized the design vision for this product by saying that a qualified user should be able to apply on their lunch break, and be covered under a new policy by midnight. The application is necessarily quite restrictive, but on average around 20% of users qualified for the fully digital experience with zero manual underwriting.

I summarized the design vision for this product by saying that a qualified user should be able to apply on their lunch break, and be covered under a new policy by midnight. The application is necessarily quite restrictive, but on average around 20% of users qualified for the fully digital experience with zero manual underwriting.

Colloquial, Approachable

Insurance can be intimidating, so we needed to make the application as approachable as possible. We used colloquial language where we were not required to use specific, legally-approved phrasing. When we asked for sensitive information, we included a green notice to help build trust.

Insurance can be intimidating, so we needed to make the application as approachable as possible. We used colloquial language where we were not required to use specific, legally-approved phrasing. When we asked for sensitive information, we included a green notice to help build trust.

#Goals

I designed this entry point for the application and it tested well. It used a combination of rounded type, thin-line illustrations, and offset highlights to convey an approachable-professional aesthetic.

Sensitive Data

We often needed to ask for sensitive data. The team came up with a "green box" notification to assist in trust-building (I did not design these in particular). The boxes tested well and we used them throughout.

Split Path

Qualified vs. Non-Qualified Applicants

The system needed to account for two types of user: those who qualified for the Prosper product, and those who did not. We needed to dynamically route each type of user, providing a seamless experience for both. Thus was born the split-path architecture underlying the Prosper application.

Final form: If any applicant responds to a question in a way that requires extra attention, the system takes two steps. First, it asks one or more "reflexive" questions, digging deeper into key details. Example: a user sees the question "Have you used any tobacco products in the past 5 years?" and responds "Yes". The system then displays reflexive questions regarding product types and frequency of use. If the user's subsequent answers still allow them to qualify for the Prosper product, then they continue with the digital application. They can still sign paperwork and gain coverage by midnight.

The system needed to account for two types of user: those who qualified for the Prosper product, and those who did not. We needed to dynamically route each type of user, providing a seamless experience for both. Thus was born the split-path architecture underlying the Prosper application.

Final form: If any applicant responds to a question in a way that requires extra attention, the system takes two steps. First, it asks one or more "reflexive" questions, digging deeper into key details. Example: a user sees the question "Have you used any tobacco products in the past 5 years?" and responds "Yes". The system then displays reflexive questions regarding product types and frequency of use. If the user's subsequent answers still allow them to qualify for the Prosper product, then they continue with the digital application. They can still sign paperwork and gain coverage by midnight.

Qualified vs. Non-Qualified Applicants

However, if their responses require a human to assess their situation, then the system flags them for "manual underwriting". That user is unable to complete the full digital application, but may still answer several more questions to help find their best fit. Over time we determined that around 20% of applicants qualified for the full digital application, while 80% were still eligible for other products.

However, if their responses require a human to assess their situation, then the system flags them for "manual underwriting". That user is unable to complete the full digital application, but may still answer several more questions to help find their best fit. Over time we determined that around 20% of applicants qualified for the full digital application, while 80% were still eligible for other products.

Convergence and Divergence

Periodically, the user flow would converge into segments that were universal to all users (such as designating beneficiaries), and then diverge again into separate "Prosper" and "Non-Prosper" flows.

Unique Question Sets

Prosper-qualified users saw a unique set of questions that allowed them to complete the application 100% online.

Simple Experience, Vast Flow

Displaying the full flow here conveys the scope of the project. It asks questions regarding demographic, finances, health, and much more. Those who qualify can designate beneficiaries and sign all required documents completely online. In order to allow both users who did and did not qualify, I needed to create a split-path workflow that allowed everyone to complete some form of application.

An Exciting Design Challenge

Reflexives: Flying Blind

All Prosper-qualified users needed to answer a set of underwriting questions regarding things like health history, substance use and more. Our underwriting partner supplied those questions via API calls, which were themselves based on user responses. So each new question could be different depending on how the user answered the last one. Therefore I needed to design a system that could "fly blind" with no way of knowing what the questions would be, how many there would be, or how long the session would take to complete. That ruled out several patterns that can help with long processes: i.e. previewing the next question, or showing any form of progress indicator.

All Prosper-qualified users needed to answer a set of underwriting questions regarding things like health history, substance use and more. Our underwriting partner supplied those questions via API calls, which were themselves based on user responses. So each new question could be different depending on how the user answered the last one. Therefore I needed to design a system that could "fly blind" with no way of knowing what the questions would be, how many there would be, or how long the session would take to complete. That ruled out several patterns that can help with long processes: i.e. previewing the next question, or showing any form of progress indicator.

Pattern: Page Progression

To build such a design system, I used example JSON returns supplied in our partner's API guide, accounting for all response and input types: booleans, multi-select (checkboxes), free-text input, numerical input, drop downs, and more. Engineering appreciated the straightforward, plug-and-play approach which did not require them to combine or restructure any text. This also allowed for a cleaner legal review process, with required language represented 1:1 from our partner's database through to our front end.

To build such a design system, I used example JSON returns supplied in our partner's API guide, accounting for all response and input types: booleans, multi-select (checkboxes), free-text input, numerical input, drop downs, and more. Engineering appreciated the straightforward, plug-and-play approach which did not require them to combine or restructure any text. This also allowed for a cleaner legal review process, with required language represented 1:1 from our partner's database through to our front end.

On-Page Reflexive

Some pages would pre-load and display reflexive questions, so that they showed immediately after triggering. This was one useful pattern for making a long process feel moderately shorter.

The System at Work

Above is an example of the complex underlying design structure providing a simple front-end experience. Title and drop downs are populated. One answer has been selected.

Reflexive Example #1

These are some of the reflexive questions that a user could see when they provide information about their alcohol usage.

Reflexive Example #2

These are some of the reflexive questions that a user could see when they provide information about their THC usage.

Wait Time: A Crucial Bottleneck

Unpredictable API Calls

Third-party API calls could take time, and we had no way of controlling that. We could, however predict several points in the flow when those wait times would occur. A wait time of longer than 10 seconds is dangerous in internet-years, so we needed a way to keep people in the experience even when things took a while. The team and I arrived at three "wait-time masking" strategies based on the shortest, middle, and longest predicted wait times.

Third-party API calls could take time, and we had no way of controlling that. We could, however predict several points in the flow when those wait times would occur. A wait time of longer than 10 seconds is dangerous in internet-years, so we needed a way to keep people in the experience even when things took a while. The team and I arrived at three "wait-time masking" strategies based on the shortest, middle, and longest predicted wait times.

Successful Strategies

For ultra-short short wait times (2-seconds or less), we simply displayed a spinner. For short wait times we displayed a testimonial carousel, using the delay as an opportunity for trust-building. During medium-length wait times we invited interactivity, displaying a "How did you hear about us?" question. For longer wait times, we considered displaying a video, but ultimately decided to take the interactivity further–displaying additional questions from our own servers. All three strategies tested well. Not only did they keep users in the flow, they created additional value for Amplify through building trust and acquiring valuable user data.

For ultra-short short wait times (2-seconds or less), we simply displayed a spinner. For short wait times we displayed a testimonial carousel, using the delay as an opportunity for trust-building. During medium-length wait times we invited interactivity, displaying a "How did you hear about us?" question. For longer wait times, we considered displaying a video, but ultimately decided to take the interactivity further–displaying additional questions from our own servers. All three strategies tested well. Not only did they keep users in the flow, they created additional value for Amplify through building trust and acquiring valuable user data.

Wait Time Flow Chart

This deliverable outlines the path for engineering during the longest expected wait time of the flow.

Ultra-Short Wait Time

For ultra-short wait times we used a simple spinner.

Medium Wait Time: Invite Interactivity

For wait times in the 10+ second range, we invited interactivity and gathered user data.

Short Wait Times: Build Trust

During short wait times (10 seconds or less) we displayed a testimonial carousel to build trust.

Long Wait Times: Gather Data

For long wait times we inserted questions from our own servers, seamlessly transitioning back to the API-supplied questions when they had loaded.

Collaboration

Sanity Checks

I had regular meetings with the PMs to course-correct on product direction and details. We ran new ideas past engineering, through meetings and slack, in the form of both static Figma-mocks and prototypes.

I had regular meetings with the PMs to course-correct on product direction and details. We ran new ideas past engineering, through meetings and slack, in the form of both static Figma-mocks and prototypes.

Partner and Legal Feedback

The interface was subject to review from several parties, including our own legal team, the legal teams of multiple partners, and government regulators in each US state. I made adjustments as needed.

The most difficult part of the legal review process was the tension between "legal-ese" language and my desire to keep the application approachable, and to some degree colloquial. I was able to get a few especially opaque phrases officially updated, a process that took weeks and required dozens of worker hours on various teams.

The interface was subject to review from several parties, including our own legal team, the legal teams of multiple partners, and government regulators in each US state. I made adjustments as needed.

The most difficult part of the legal review process was the tension between "legal-ese" language and my desire to keep the application approachable, and to some degree colloquial. I was able to get a few especially opaque phrases officially updated, a process that took weeks and required dozens of worker hours on various teams.

Feedback Example #1

Instructions to update the copy for a draft of the "declined" page, after which we would refer a user to another provider.

Feedback Example #2

Instructions to update the copy for a draft of the final page, after a user had accepted and signed their policy.

Sanity Check: Prototypes

I created prototypes as a way to help engineers understand certain crucial flows, and to check for blind spots before handoff.

Delivery & Meta

Delivery

Deliverable Format: Figma link.


Structure: I designed the interface largely using the Style and Component library that I created and maintained for the Product team (pulling in many contributions from others), which is based on the atomic framework. Engineering maintains a copy on their end.

Deliverable Format: Figma link.


Structure: I designed the interface largely using the Style and Component library that I created and maintained for the Product team (pulling in many contributions from others), which is based on the atomic framework. Engineering maintains a copy on their end.

Specs and Instructions

Reducing engineering lift and helping with clean execution means not just designing with modularity, but leaving clear instructions. I left annotations throughout the deliverable to assist engineers in execution. The metric of success here is to have as few questions as possible after delivery. Where necessary, I mocked up animations to demo behavior.

Edge Case Examples:

  • Notes in the "Beneficiary" section cover an edge case in which a user indicates their relationship with the beneficiary is "Other".

  • Instructions in an early form of the "Wait Time" section cover flows that include unreasonably long wait times, in which we would send an email when the user had received an approval decision.

Reducing engineering lift and helping with clean execution means not just designing with modularity, but leaving clear instructions. I left annotations throughout the deliverable to assist engineers in execution. The metric of success here is to have as few questions as possible after delivery. Where necessary, I mocked up animations to demo behavior.

Edge Case Examples:

  • Notes in the "Beneficiary" section cover an edge case in which a user indicates their relationship with the beneficiary is "Other".

  • Instructions in an early form of the "Wait Time" section cover flows that include unreasonably long wait times, in which we would send an email when the user had received an approval decision.

Beneficiary Edge Case

Accounts for an edge case in which a user indicates their relationship with the beneficiary is "Other".

Early Wait-Time Masking

The screenshot above displays in an early form of the "Wait Time" section. It details a flow to account for unreasonably long wait times, in which we would send an email when the user had received an approval decision.

Final Outcome

My designs helped launch the first 100% digital IUL insurance application. The final interface operated as an autonomous system, using our parter's API guide to ensure it could parse and display any conceivable underwriting question. This allowed Amplify to become an insurance carrier, and to launch its new product, "Prosper IUL". It was approved by the legal departments of all corporate partners, and government regulators in all 50 states.

My designs helped launch the first 100% digital IUL insurance application. The final interface operated as an autonomous system, using our parter's API guide to ensure it could parse and display any conceivable underwriting question. This allowed Amplify to become an insurance carrier, and to launch its new product, "Prosper IUL". It was approved by the legal departments of all corporate partners, and government regulators in all 50 states.

Yahoo Finance

An article from Yahoo Finance announcing the new product.

Global FIntech

An article from Global Fintech announcing the new product.

PR Newswire

An article from PR Newswire announcing the new product.

Future Opportunities

Different Policy Types

Having built the infrastructure for one policy type, it would be much easier to add new products, including Term, VUL, and Combination policies. In fact, I created designs for these early on, anticipating that we would expand the product line one day.

Having built the infrastructure for one policy type, it would be much easier to add new products, including Term, VUL, and Combination policies. In fact, I created designs for these early on, anticipating that we would expand the product line one day.