American Express
Designing the save card feature for paying invoices
OVERVIEW
THE TEAM
RESULTS
THE PROBLEM
USER FLOWS
DESIGN
ITERATION
RESEARCH
DEVELOPMENT
LEARNINGS
American Express Payment Accept users use our platform to send invoices and take card payment. Before this feature release, their customers had to enter their card information every time they needed to pay off an invoice. My team and I worked on a feature to allow customers to save their cards for a faster payment process.
As one of two designers on the Payments team, I led this project from 0 to 1. I piloted a more formal design process with the engineers and PMs that helped us keep to the project timeline. I set up a kickoff meeting to gather requirements, had recurring design critiques and syncs with the team so they were informed of the UX process through the entire process.
Since release, we’ve had about 80% of Payment Accept users utilize the feature. When comparing task completion time, we also saw a 50% decrease in the time spent paying an invoice.
The experience for paying an invoice was that a customer would receive an email to pay an invoice. They would view the invoice and be required to manual enter in their card information to make the payment.
A big improvement to the quality of life to the users was the ability to save card information on platform so customers would have a quicker and easier checkout time.
When I approached the problem, I first needed to understand the scope of it and after meeting with the engineers and PMs, I identified the main user flows I needed to solve for.
I began rapid ideation and created screens for a few options. I started on mobile responsive designs to make sure the layout made sense - the cards, the validation and option to remove all needed to live on the page. I shared these designs with other designers where I got feedback to help narrow down to the best design. From there, I thought through all the error cases and laid out the flow to present to the product and development.
Involving the dev team early was critical for this project. We were able to discover a lot of technical limitations during this time which helped the team a lot. Requirements were not defined for this project which meant design got to drive a lot of the conversation but also that we were discovering the feasibility of the design during the team syncs.
For the error states, I proposed being able to edit a card if it had expired or was lost. However, we discovered that we didn’t actually store card data and thus users would not be able to edit a card. So I pivoted the design where cards would be in a disabled state and can only be removed if a saved card information was changed or expired.
I worked with our research team to launch a user testing session with 5 users. This was mainly to ensure usability of the design. We asked users to complete 4 tasks: 1. Pay with card and save card 2. Pay with save card 3. Resolve expiration date issues 4. Use different card for payment.
When compared to historical data, users typically spent twice as long on each task. This was a great metric to show the value this feature would have. I also was able to apply additional copy feedback from the research to the designs before packaging the Figma file up for our developers.
Another issue arise during development where we couldn’t use CVC to authenticate a card. This meant I had to rethink the design and from the options we had, I proposed updating the design to using expiration date. Once the engineers validated that solution, I worked to update and deliver the Figma files. Through teamwork from the entire team, we were still able to deliver and launch the feature on time.
Since the launch of the feature, our customers have been very satisfied with the new checkout and we’ve seen high utilization of the feature. About 80% of users who user Payment Accept have used the feature at least once.
Some key takeaways from this project were:
Involve partners from the beginning - With constant communication, we were able to descope a lot of nice-to-haves such as scheduling payments and merchant-side customer management and really focus on a MVP to launch the feature to users sooner.
Be flexible - Sometimes technical limitations aren’t discovered until later, and as a team, we were able to be flexible and work together to not delay the launch.