Automatic Payments for Card Clients

Challenge: Provide credit card users the ability to set up and manage automatic payments (recurring) on their credit card accounts. Additionally, migrate a few thousand customer's off of an antiquated third party solution to the new autopay experience.

Solution: Through discovery research, client call center and survey CX data, competitive analysis, ideation, and usability testing, design a solution to meet clients' needs for efficiency and convenience.

A lean UX approach using a compact design sprint

I began to do research and understand the problem space. Insights and notes from previous user interviews, where I was the observer and a UX Researcher moderated, were helpful secondary research. This was research on clients for related projects, and that led to our 4 main personas. I also had access to customer feedback documented by the client call center. I then developed a project How Might We statement by facilitating a team problem framing session to gain alignment. I did a partial heuristic analysis of the old experience and some competitors and then continued to think through the lens of the established personas.

How might we provide clients with a clear and concise way to automatically pay their credit card bill, in order to ensure they won't miss a payment?

The whole thing mapped out

Even before everything being virtual, our group would use online whiteboard experiences to cluster, find patterns, document, and collaborate. After this initial research, I began to think through potential user flows, which I shared with my team to help them visualize the feature. Then, in this particular project, I was ready to facilitate an ideation session of crazy 8s. I did this in order to give visibility and alignment with my team, as well as generate permutations.

From sketch to screen

The following slides are sketches from crazy 8s, a user flow, iterative wireframes, and a higher fidelity prototype.

Validation

I engaged my team, product, and development to review the ideations, and then had people vote. I focused on the sketches that drew the most votes, but more importantly I elicited verbal responses on why people voted the way they did. I then created lower fidelity wireframes, got more feedback, and then eventually designed higher fidelity prototypes for usability testing.

Prototype for autopay on desktop

Evolution of the design

In general, ideation evolves from the initial research, and the prototypes evolve from ideation. From there, the feedback from customers in usability testing helps to further shape the final product. The following improvements are the result of that evolution.

Vertical Form

The form utilizes a best practice by vertically presenting each form element, with the labels above each element. Previously, the labels were to the left of the form elements. Form elements were also presented in sections that were inconsistent and misaligned from each other. There was no consistent design system used.

Make amount use radio buttons

The amount section was originally placed inside a dropdown. In order to present 3 choices clearly to the customer, they were designed as radio buttons.

Payment Date

Based on feedback from the usability studies, different ways of allowing customers to choose when the autopay would post each month, created some confusion for some of the participants. Too many choices, and what those choices meant, made some participants second guess themselves. Our clientele is, in many cases, affluent and older. They want to feel secure and have clarity in their actions.

The fixed date was a way to simplify and give assurance that their payment would be paid on their due date. In fact, it also reminded them of their due date. It spelled it out: “Pay on Due Date (23rd of every month).“ There are two less clicks or taps to make, and there is no ambiguity over when the automatic payment will post each month.

A simple navigation

In the older version of autopay on the third party website, the customer is interrupted from their task to set up autopay by an over-cluttered left navigation, links to add a payment account, and view payment history. To help the client focus on their task, these were removed from the top and organized into a clean left navigation.

AutoPay in the mobile app

Eventually, we had the same need for AutoPay to be active on our native app. I knew a fair amount about AutoPay, but not entirely through the lens of a mobile-specific user. What were their needs like? I settled on the right persona, who was more 'on the go', and wanted quick access. Then through another ideation session, I produced iterative prototypes in Figma and validated through usability testing.

Prototype for autopay in the mobile app

Results