Payment Flow

A workflow to reduce time to complete an order and save the business money
Problem

How can vendors and real estate agents complete their real estate photography orders quicker? How can the business save money by building their own payment processor rather than paying transaction fees to a third-party processor?

Project Requirements
Provide a seamless UX, with limited redirects:
When it came to analyzing our current payment flow, I realized that the amount of popups and redirects to Stripe/Square could be putting increased cognitive load on our users. Rather than being able to complete their payment in one go, users were forced to go through many clicks to achieve simple actions, such as adding a tip, entering a promo code, or providing their credit card details.
Maintain a uniform entry points to the payment flow: In order to make sure that all of our users have a uniform payment experience, I needed to map out all of the flows that could potentially lead to payment collection. I had to consider all the various features that would have to be maintained with this payments redesign, namely the ability to collect full, partial, or no payment, option to pay with Apple Pay, and option to pay with saved cards or new cards. Given that certain flows would be used by different users, for instance, vendors or their customers, I needed to understand the information that will be most pertinent for them to be able to complete the payment flow.
Make this the default service provider: Before this project, the business was paying more for credit card fee transactions to Stripe and/or Square. As such, they decided to develop their own processor. However, by doing so I needed to make sure that our payment processor was much better than the competition.
Snippet of interview guide to understand users' pain points with the current order form.
Portion of the analysis work done in Dovetail.

User Research

Before working on any designs, I needed to get a better understanding of what our users need from this payment processor. First, I went through Canny posts to get insight into some of the needs that our users were voicing regarding using key words like "payments," "order placement," and "order form." To strengthen my secondary research efforts and get qualitative insights I conducted generative user interviews. I started out preparing a user interview guide that would help me in conducting interviews with users who have placed the highest amount of orders.

After completing 10 user interviews, I analyzed these interviews in Dovetail. With this analysis, I realized that my assumptions regarding the cognitive load of the redirects, multiple modal and clicks were misguided. Most users didn't find these cumbersome and, in fact, many of them were wary of using our payment processor and didn't feel like they could trust our processor when compared with more established processors like Stripe or Square. Further, I realized that many of the benefits of Aryeo payments would actually come from adjacent technical ramifications of this processor, such as being able to process refunds internally, having the option to store and validate credit cards, being able to automatically calculate sales tax, and being able to provide invoices.

Wireframes exploring promo code and tip placement with a split screen order form layout.
Wireframes exploring solutions for displaying order details before finalizing the order.  
Wireframes exploring tip selection for an order, payment with a saved card or ApplePay, and application of a promo code. 

Wireframing

As more stakeholders started contributing to this project, offering multiple new viewpoints to the table, I had to iterate several times during the course of the project. Many of these iterations consisted of small visual changes, such as defining an alternate layout and better presentation of the key functions of the page.

Multiple types of flows were wireframed to show key workflows such as paying with a promo code, adding a tip to the order, or doing a partial payment. Some of these options are shown on the right.

An obstacle that I encountered in this part of the process was trying to balance stakeholder input as well the best experience for users. As such, I had to cycle between wireframing and high-fidelity mockups/prototypes as stakeholder priorities were changing. This project followed a very iterative design process.

Payment pages showing items in cart and payment method
Views for a flow with saved cards and full payment required upfront.
Mobile view showing responsive version of the order form with partial payment required and credit card form field.
View with no payment required upfront.

High-fidelity Mockups and Prototyping

After wireframing helped me to define a layout and the best way to format and present information, I moved on to create high fidelity desktop and mobile mockups for the following user flows:
- Flow 1: full payment, saved cards, add tip, add discount, option to pay with Apple Pay, apply credit
- Flow 2: partial payment, no credit, no saved cards
- Flow 3: no payment
-Flows 4 & 5: order edit page slideover for the vendor UX and the customer UX

I was able to craft these higher fidelity designs by taking advantage of the design system already established by the business. Due to this, all the components necessary for this solution were already available.

Key Results

100%
Reduction in redirects leading to a seamless in-platform experience
$0.05
Amount saved per transaction by the business with users adopting the new in-house payment processor
3+
Number of projects in the roadmap this project inspired  

Project Learnings

01
Establishing who the stakeholders are before initializing a project
While the design process is iterative in nature, the process can become complicated when we don't have all the necessary stakeholders participating in the project from the get go. As people join in later on in the process, it becomes harder to accommodate and implement everyone's insights. This experience has taught me to make sure that before I start any project, I should first make sure I know who the key decision makers will be on the project.
02
More user (usability) testing of prototypes
Due to the time constraints involved in this project, I wasn't able to test out the latter-stage prototypes with the users. This was a significant concern of mine because many of the decisions we made during the wireframe iterations were not backed up by user research. However, thankfully, some of this user testing was accomplished through an adjacent project I did, which helped me to see more clearly the areas of improvement for this payment project.
03
Business needs don't always match user needs
While the business decided it would be financially advisable to build their own payment processor, when testing with users, they actually entrusted the existing third-party solutions we had been using up to that point. In cases when a reduction in cost trumps user's trust in a novel solution, it's important to carefully consider key decision factors that users may have for or against using a novel solution.
04
Being aware of scope creep
Given that this project went through several iterations before final approval, I've learned through this project to always cross-check with the original project requirements to ensure that the design is not trying to accomplish too many extraneous items that were not planned for at the project's onset.