Payments Redesign
⬥ Client project ⬥
Ongoing initiative to redesign the AutoPay and Manage Bank Account experiences in web and app for Discover Financial Services.
Duration
Timeline
Role
Platform
Tools
8 months (ongoing)
February 2024 - present
UI Designer
Web & Mobile
Figma, Miro, Rive
INTRODUCTION
⬥ the brief ⬥
Who is the client?
Discover Financial Services ("Discover") is a leading financial services company known for its credit card offerings, banking products, and consumer lending services. Founded in 1985, Discover is recognized for its commitment to customer service, innovative financial solutions, and rewards programs. It operates the Discover Card, one of the major credit card brands, and is noted for its robust online banking platform (Discover has a single brick and mortar storefront in Delaware).
What is the business problem?
Today, Discover's credit card payment experiences are enabled on Web and Mobile App (iOS and Android) with their legacy UI from approximately 10 years ago. As new business, technical, and user requirements have evolved during that time, short-term "bandaids" were implemented to address these requirements incrementally. Over time and with the evolution of product requirements, the payment experiences became disjointed and riddled with friction points for customers and the business.
What are the project's goals?
Through a collaborative effort with Discover and FCB, the project adopted three main goals:
1
Redesign the AutoPay and Manage Bank Account flows in Web and Mobile App for MVP1 to reduce breakage, remove friction, and enable greater digital self-service.
2
Update the User Interface of the payment experiences, leveraging Discover's Design System (1.0) components and design language .
3
Address new regulatory requirements (NACHA) to give users the ability to download and print transactional details.
⬥ THE approach ⬥
How do we tackle this brief?
GETTING STARTED
⬥ ABSORB ⬥
Where do I start?
My first order of business was to absorb everything about the brief and probe where I found gaps or assumptions. Much like other assigned projects for Discover, I was the "creative lead" for this initiative with minimal oversight from the SVP of Creative for the Discover account so it was important that I set a good foundation for myself before diving into high fidelity designs.
I requested access to and reviewed the following documentation:
Project Kick-Off Deck: the project kick-off deck provided additional context on the client's problem, the request, and project goals.
Wireframes: the wireframes created by the UX architects provided the base screens and general user flow of the new payment flows.
Competitive Analysis: the UX architects conducted desk research on how banking competitors like JPMorgan Chase, American Express, and Wells Fargo solutioned for AutoPay and Manage Bank Account flows. These flows are common and necessary to provide in the financial services space.
Miro Board with Client Presentations: due to clients' unfamiliarity with Figma, the Discover team at FCB leverages Miro to present designs and receive feedback from the client. While I can find the designs in the Wireframes Figma file, I requested access to the Miro board so that I could read the clients' sticky notes throughout the wireframe phase and understand previous sticking points, unresolved questions, and feedback that were relevant to UI Design.
⬥ probe ⬥
What gaps exist?
Though the clients had approved the wireframes, thus kicking off the UI Design phase and initiating my involvement, they often have a difficult time reviewing wireframes and envisioning the bigger picture. For this reason, many requirements are left undiscovered and unaddressed at the beginning of the UI Design phase. This is why I take the effort to review documentation and ask very specific questions that may realize additional requirements and/or constraints. Listed below are a sampling of the questions I had after reviewing the documentation:
Overall
• The brief lists resolving "bandaids" implemented over time as a project goal. What are those bandaids? What was the problem that led to needing this bandaid?
• What / where are the pain points in the current state? How and how often are customers impacted by these pain points?
• Are there regulatory requirements we need to address?
• The wireframes only included base states and the "happy" path. What are all the screen states needed? What are all the use cases that need to be addressed?
Manage Bank Accounts
• How many bank accounts do users have? What is the range?
• Are users able to define a default bank account across payment products?
AutoPay
• When do users enroll in AutoPay? During onboarding? 1 month after account activation?
•Are there cutoff dates to make edits? When does the AutoPay process run? Are there timing gaps we need to account for and keep the user informed of?
To resolve these questions, I scheduled time with the lead UX architect and Account Director. For most of these questions, the team did not have an answer, unfortunately. We aligned on best guesses and assumptions, however, for me to be able move forward with bringing the wireframes to life. I documented each assumption and open question to review with the client during Round 1 delivery.
ROUND 1 DESIGNS
⬥ SOLUTIONING ⬥
What could these screens look like?
The challenge in this project for designing high fidelity screens is two competing priorities from the client:
Comply with DDLS 1.0, which is outdated and lacks robust documentation
Make the designs look fresh, modern, and delightful to the user
Though Discover's Figma UI Kit helps bring designs together more quickly, it also requires deep knowledge to understand how components should be utilized, how they're used in the current production environment, and where there is flexibility to make different design decisions. With some components, there is a lot of creative freedom; with others, their use must be carefully vetted.
With this in mind, I created each screen of the AutoPay and Manage Bank Accounts flows, leveraging components like Text Link, Selector Button, Radio Button, Primary Button along with text and color styles.
ROUND 2-5 DESIGNS
⬥ ITERATION ⬥
How many rounds will it take?
FINAL DESIGNS
⬥ DECIDE ⬥
What are we moving forward with?
Over the course of 6 rounds, I identified requirements, identified business and technical constraints, and sought critical feedback on the UI details (layout, composition, accessibility, illustrations, motion, etc.) in order to deliver the final designs for enrolling, editing, and canceling AutoPay. Key clarifications and decisions included:
Technical
Customers may have 1-8 bank accounts.
Customers are not able to set a default bank account.
Bank accounts are ordered alphanumerically by Nickname
In the case no Nickname is defined, the Bank Name is the Nickname
Customers may enter an amount between $1.00 - $100,000 for Custom Amount
Customers may enter an amount between $0.01 - $100,000 for Minimum Payment Due + Fixed Amount
The platform can not prevent an Automatic Payment to be processed because of a manually scheduled payments.
The Add New Bank experience must be within a modal with an overlay
Business
Customers who are delinquent must call customer service to edit AutoPay
Customers must be informed of how their payment is protected
Edits to AutoPay can only go into effect in the next most recent AutoPay cycle if the edits are made 24 hours prior
If edits are made within the 24 hour window, they will go into effect for the next billing cycle
Customers must be informed if a payment is already scheduled
Regulatory
Customers must have the ability to download and print transaction details
Customers must opt-in to AutoPay
No bank account shall be defaulted into the bank account field when a customer is enrolling in AutoPay
Sampling of Screen States
Sampling of Screen States
CONCLUSION
⬥ NEXT STEPS ⬥
Great! What next?
The client and business partners were very happy with the designs for MVP1 of Payment Redesign. They appreciated the amount of thought that went into the designs and the discovery of requirements that they had not considered.
As for next steps…
1
Annotate designs prior to dev handoff
Using our annotation toolkit, the UX architects will go through the final designs and annotate them for reading order, focus order, any alt text, and the behavior of interactive elements. I am not the driver for annotations but will remain involved to answer any questions, particularly in regard to the behavior of interactive elements.
2
Create the legal deck for legal approval
In parallel to annotations, I will be tasked with creating the legal deck for the project in Adobe InDesign. For this project, I expect no less than ~80 pages to document all of the screens, screen states, and use cases.
3
Prepare design assets for dev handoff
Prior to handoff, I will go through the final designs one last time and mark them as "Ready for Dev" in Figma. I will also ensure all of the assets are prepared and ready to go (ex: the check illustration and animation as well as the AutoPay illustration and animation).
⬥ key LEARNINGS ⬥
What did I learn through this project?
1
Being proactive by asking questions and identifying gaps is key
Real life projects are messy for a lot of different reasons - information siloes, competing priorities, lack of governance for decision making, etc. Going into a project expecting some hiccups and being proactive can make a big difference in the outcome (like "only" having 6 rounds of design instead of 15 but still accounting for all of the identified use cases).
2
Documenting design rationale in a shared workspace is critical for group alignment
People are busy, distracted, and have bad memories. And that's okay because it's part of the human experience! To be successful, though, I needed everyone - clients, business partners, and internal team - to come into design reviews recalling past decisions and leaving understanding why we just made the decisions we did. Noting where we have flexibility and providing guidance for decisions and documenting design decisions and rationale for each round helped our team stay efficient and focused. We didn't dig up old conversations. We were always moving forward and building on the previous round.
3
Including people who understand the business and the people who understand the technology EARLY is important
This project was one of the first projects where we included business stakeholders and developers in every round of design. At first, it was jarring to Account Management - there are so many people! there is so much discussion! But I absolutely loved it and encouraged it because their input made the designs so much better. Instead of me talking for 45 minutes straight, I would present each design element and pause, specifically ask if there were any business or technical considerations that we might have overlooked or not known about. This opened the door for non-designers to chime in on the designs and feel a sense of ownership over them.