Project Overview

Team: PM, Engineer, Data Scientist, Student Support Representative‍

My Responsibilities: Solution exploration, ideation, rapid prototyping, testing

Timeline: May - June 2021

Edquity Emergency Aid is a mobile app that disburses cash assistance to financially vulnerable college students during times of high-crisis. We saw the potential to transform the lives of students through faster, equitable access to emergency cash assistance, and developed an evidence-based technology that supports equitable and fast distribution of emergency aid funds.

In this case study I dissect how we researched, strategized, designed, and eventually launched a revamped payments system that would serve as a blueprint for how we would solve our ongoing payment challenges at scale. This was an accelerated project with the majority of the work completed within three weeks. We were on an extremely tight timeline because of tremendous business pressure to ship the revamped system. In one month, we were able to collaborate on the brand new, from-scratch architecture and enter the following quarter with a payments system that could support our growing disbursement volume and disburse funds efficiently, equitably and easily.

‍

‍

‍

Problem

We rolled out the first iteration of our payments system in late 2019 and it was sufficient for establishing proof-of-concept in our early pilots. The plan was always to scale our payments system after we’d addressed some other more urgent product issues. But then the pandemic hit, and there was an insurgence of interest in critical cash assistance at the national level. From a user growth perspective this was great, but the V1 of our payments system was not equipped to sustain such rapid scaling. This resulted in far-reaching issues across the organization.

‍

So we launched a work-stream to fix the payments infrastructure. I led a kickoff workshop with a representative from each of our key internal stakeholders groups to align on the biggest pain points/highest-impact area(s) to address, how success would be defined/measured/revisited, and ultimately ensure that we were working towards a comprehensive solution.

‍

‍

‍

‍

Data and Insights

There are many nuances with our payment experience relating to fees, timing, transferring to banks and types of payments. Our most frequent support cases come from issues related to our payment system. Digging into our support ticket data, we discovered that payments-related issues were the number one reason for tickets.

70% of support tickets stemmed from a payment-related issue
Of that, 30% were due to user error (selecting the wrong payment method, incorrectly entering information, etc)

‍

Our users were understandably vocal about their frustration on social media, in app store reviews, and in their responses to the quarterly surveys our marketing team sends out.

‍

‍

Thanks to product analytics, support ticket metrics, and user survey feedback, we were able to quantify the scale and impact of the problem. but we didn’t fully understand the why behind the numbers. So to add some color to the analytics and paint a more vivid picture of the people behind the problem, I combed through our research pipeline and set up user interviews. The common thread though these conversations was deep sense of frustration at the lack of transparency, convenience, and inclusivity in the payments experience.

‍

‍

From our research, we knew we needed to accomplish three things:

1. We needed to design a system that provided users with more control and flexibility on when, where, and how they were paid.
2. We needed to be able to guide users through the payment process and provide feedback on the status of their payment.
3. We needed to provide more accessible and thorough information to educate users about payment methods.

The biggest design strategy challenge was reconciling the desire to have an intuitive, simple front-end flow with the complex back-end architecture and third party limitations.

‍

‍

Process

Because of timeline constraints and tremendous pressure from upper management to get something out the door as soon as possible, we had to prioritize the highest-impact solutions to focus our immediate efforts. We started white-boarding a few concepts around two high-impact area: payments selection and bank account connection.

‍

‍

‍

‍

Re-designing the payment selection experience

One of the highest impact solutions I designed and tested was the payment selection experience. We determined where users select the payment methods was one of the high impact areas. We knew that the majority of pain points were associated with the payment selection experience.

Goals

UX: Our research revealed that one cause for this was a lack of education on payment methods generally. So in redesigning the payment selector screen, our goal was to inform the user about the trade-offs of different payment methods prior to selection.

Business: Some customers would only support one payment method while others may support all three. The design needed to be dynamic and scalable, since we also planned to introduce additional payment methods down the line. The prepaid card payment method is also significantly more expensive than the other methods, at $5 a transaction compared the $0.95 fee per transaction for direct deposit. We needed to find a way to disincentivize users from choosing this option unless it was the only viable option, which is the case for unbanked students.

‍

Wide Explorations

I dissected payment flows in checkout experiences and P2P flows to better uderstand our users mental models around payment selectors. After hashing out ideas and flows on whiteboards, I started to design variations in Sketch. I would show my team the designs I was most confident about, then get feedback and go back the drawing board for another iteration on the designs. Every single detail was nuanced, and I felt as if I was trying to put all these important pieces together into a jigsaw puzzle.

‍

‍

Initial Concepts

My initial concepts were  based on my hypotheses about what critical information needs to be surfaced at this decision point. Iexplored different ways of separating and grouping sets of information while still exposing all the options to the user.  I filtered out selection controls that did not make it clear that that this is an interface where one selection has to be made among a list of two or more mutually exclusive options.

‍

‍

Testing

Assumptions: For this kind of hypothesis-driven approach to actually yield better designs, we have to actually put these concepts in front of people. I was baking a lot of assumptions into the design so it was also imperative to actually test and validate (or not validate) these assumptions.

‍

‍

Testing helps me identify three things: what I'm confident works, what I'm somewhat confident works, and what I'm unsure of. Assigning these confidence levels helped me recognize what needed more work.

‍

After a round of testing we realized that sensitivity was an important consideration and one that we hadn't factored into the design. We heard feedback that the 'payment method' framing left users confused about whether they were the ones getting paid or paying. The labels that we hypothesized would help users make more effective and efficient decisions had the opposite effect, and evoked strong feelings of shame. And between the icons, text, and labels on the screen, users were left feeling overwhelmed.

‍

‍

After dissecting feedback, I went in a slightly different direction and experimented with radio buttons and progressive disclosure, which is fairly pretty common in payment flows. I did some explorations  around progressive disclosure and a more minimal interface, where only the description, fields, and buttons for the selected payment method are shown to the user, and all content for the non- selected methods is minimally exposed or collapsed.

‍

‍

But through testing we discovered that we were not exposing enough information. We observed some users selecting every single option, one by one, in order to gather information. While for some other users, there weren't sufficient affordances to let them know they could select an option for additional option-specific information.

"At first I didn't realize I could even select it to see more information. I'd rather see all the information at once. Having to go through the options one-by-one is frustrating"

‍

I scrapped the minimal exposure and progressive disclosure approach and moved in a direction where options are fully exposed. In testing, the radio button selection control made it clear that user can only select a single option, while still exposing all options. Another unexpected benefit was that students felt like the radio buttons were familiar ubiquitous since they're also  used in the FAFSA applications  and various school systems.

‍

‍

In this iteration, I made a couple of iterative refinements here. The first was shifting the language from "payment methods" to "receiving fund" to remove any confusion about which direction the payment was flowing in. A default choice with expanded fields provides a clear path for users who may be slightly in doubt, while still keeping the alternative payment methods clear to users who know which alternative they are looking for. I also reduced visual clutter by removing unnecessary labels. Though the interface has been pared down, we are still surfacing critical information, time to delivery and a brief overview of the option.

‍

‍

Final Solution

After many many explorations, feedback cycles, and iterations, we ended up with our final solution.

‍

‍

Clicking on the learn more button triggers an embedded web view to open in the app. All of our Help content lives within the Edquity Help
Center. We parsed student support ticket data to compile a list of the most frequently asked questions regarding payments.

In organizing this information, I made the top-level categorization stage of the experience and sub-categorized it by payment option. We directed users to the content across all our in/out-of-app touch-points. After discussions with our Engineering lead and PM, we decided that the Help Center would live in Intercom instead of building out a custom, in-app Help Center. Our rationale was that this would maximize our limited engineering resources and ensure that our Support team could easily modify/add content directly in the front-end based on evolving user needs.

‍

‍

‍

High Fidelity

With this project I jumped straight from lo-fidelity to hi-fidelity because the majority of our foundational UI components already existed in our component library and we’d already established reusable design patterns.

Updating UI Components

While auditing the payments flow, I discovered that we were still using the outdated filled fields instead of the outlined fields that we had shifted to and used consistently throughout the rest of the app. The inconsistent use of fields resulted in very obvious visual incongruity between payments and the rest of the app. So I successfully made the case to standardize and consolidate our use of form selects, labels, controls, and validation messaging as part of this workstream, and paired with a front-end developer to make it happen.

‍Accessibility Improvements

I had a hunch that our app had pretty low accessibility, so I tested the contrast-ratio of our primary button color to see if it met the contrast requirements. It failed, miserably. So I decided to further improve the contrast of our buttons.

‍

‍

Handoff

Because this was a complex system with divergent flows, changing states, system dependencies, and third-party integrations, we needed to restructure our handoff process. We would run the risk of miscommunications around intended behavior, feature decisions, etc. if we to cram everything into one hand-off. We decided to schedule three mini-handoffs over the course of a week. In addition to the Figma screens, I handed off a clickable prototype, a comprehensive flow diagram, end-to-end requirements table and corresponding design documentation.

‍

‍

‍

Post-Launch

Increase in disbursement capacity, decrease in support tickets

We saw a 45% decrease in payments-related support tickets 2 months after launching Payments 2.0

‍

Success Metrics

• 25% decrease in payments-related student support tickets, clearing up our student support team's bandwidth to handle more pressing issues
• 45% decrease in technical payment-related tickets, increasing our engineering team's bandwidth to focus on the product backlog
• 75% of funded users claimed funds within 1 week of approval (prior to this, only 45% were claiming within 1 week), meaning students got their funds more efficiently (which maps back to our design principles)
• Increased disbursement capacity: went from disbursing 1M -> 50M in one quarter
• Since launching V2 disbursed over $100M

‍

Lessons Learned

Security and safety (perception and actual) always matters, no matter what the task is. In designing Payments 1.0, we baked in two (wrong) assumptions i) that data security was a minimum requirement and therefore did not have to be continually reinforced/highlighted throughout the experience and ii) mentioning safety itself brings uneasiness and doubt about the system's security.  This couldn't have been further from the truth. Users were willing to pass up  on claiming up to $500 in awarded funds because of the perceived lack of security. The barebones interface led to user hesitation that affected their focus on the task at hand. Concerns about security coupled with their fundamental distrust of tech solutions and financial services led to problems with task completion.

Designing for inclusivity presents a lot of challenges that don’t come up if you are creating products for a more limited market. We constantly see how cultural context, infrastructure, and on-the-ground realities matter to good design.

Friction isn't always a bad thing. After reviewing data one theme we identified was that friction isn’t always a bad thing for the user, especially when it involves money. 30% of payments-related support tickets were stemming from users incorrectly connecting bank accounts, selecting the wrong payment method, and entering information incorrectly. More friction might make a task take longer to complete, but the user can take time to be more thoughtful about the task. 

Understand that things can break — and design workarounds for that. Digging into the data, we found that nearly 30% of our users were opting for the prepaid card due to connection issues with their bank. Furthermore, Plaid did not support connection for a handful of smaller banks.