.png)
The Add an External Account feature allows Capital One customers to link their accounts from external banks so that they can process payments or money transfers to their Capital One accounts. When I joined the team as new lead designer, the structure of the UX flow had largely been completed, but certain screens had not yet been finalized and the feature hadn’t yet launched. I was responsible for running the design baton to the finish line (shipping), and that included redesigning elements of the experience based on product objectives, research learnings, and edge cases.
Prior to our feature launch, Capital One bank customers could not use the app to add bank external accounts that would allow them to fund their new bank accounts. This feature was available only on the web although most bank transfers are made on mobile devices. And customers need to be able to add an external account when they open a new Capital One bank account for funding it -- otherwise, after 60 days, if the new bank account doesn't have any money in it, it will be closed. On the credit card side, customers were able to add accounts to pay their balance on our mobile app, but only through a flow specific to card customers.
The challenge: We wanted to create a single, streamlined experience that enables credit card and banking (all) customers to connect their accounts from other financial institutions so that they can make bank transfers and pay their balances whenever they need to.
And in addition to designing this critical banking experience, we knew we had to add clarity to the standard 2-3 day verification process users undergo when adding accounts to make transfers. Users did not understand the next steps they had to take for verification, and this was a common issue for customer support to deal with.
.png)
The crux of this interaction is having to fill out a form with the external account’s details. Before launch, our team prioritized adding the option to make the account someone is adding their default account for payments, AKA their primary payment account. But this required a disclaimer to be added to an already information dense screen. So I designed the primary payment account disclaimer to only appear after the previous row in the form is completed so that the user’s attention is drawn to reading it once it becomes relevant (rather than including it as part of the screen’s initial state).
.png)
By front loading this choice in the form we hoped to automate future payments and address customer complaints around having payments made by default from an old account. This can result in returned payments, late fees and so on. And from a business and design consistency perspective, this effort brings parity to our Android and iOS experiences (primary payment selections were at the time only available on iOS), and continues to drive our one-click payment notifications (which are dependent on a primary account being selected). A user and business win!
After joining the team, I revisited research conducted by the team's previous designer that investigated issues with task completion. We knew that after successfully adding an account that would be used for payments only, users are ready to go. But if they add an account that would be used to transfer money, they would see a Next Steps screen that explained the outstanding verification process. This process was a standard regulatory one which involved waiting 2-3 days to verify "test deposits" that the customer would receive. We found that the current Next Steps design wasn't communicating this clearly and led to frustration.
.png)
Anchoring on these key takeaways, I flared out with various new approaches for this Next Steps screen. In all of these options, I chose to semi-bold the text that acknowledged the state of the user’s account (ready or not ready) to accommodate scanning. We knew from research that comprehension on this screen was limited, and we didn't expect every user to read all of the content.
.png)
And although I recommended option 2 here, our team ultimately chose option 1 because of lack of tech feasibility in building out a new component relative to our scheduled time of release. Option 1 employed design changes that were high value (communicated sequence of steps to come and accommodated scanning) and required less overhaul. However in the end, even if at the time Option 2 wasn’t feasible, it inspired a new “vertical progress indicator” component to be contributed to our design system for iOS for future use.
Additionally, recognizing the overall frustration with this lengthy verification process, our team prioritized integrating a new “instant linking” back end, which would allow eligible customers to link a transfer account instantly! Although we couldn't provide this to all customers, we were able to establish this solution after investigating the proper regulatory checks that are needed to bypass the standard process.
.png)
When gearing up for final design revisions before passing off files to my tech teams, I had to consider what edge cases our customers could run into and what inconsistencies were there in our design files for iOS and Android. That included highlighting where in our flow we should have a different UI for tablets and iPad users (as our design system guidance wasn't fully formed on this at the time). Although they represent a small fraction of users, our team still wanted to be intentional with these customers. There were a few screens, like the one below, where I laid out a recommended change in UI on iPad to better take advantage of the screen space.
.png)
Finally, we had established some expected error scenarios and had principles around when to use which type of error experience (inline messages vs. pop up modals), but the team had noted a few new errors that could arise. I worked with a content designer for the language in our new “unhappy path” scenarios, and created a document to categorize and name all of our error messages.
.png)
And throughout my process, I took note of inconsistencies that I had inherited in the original design file (i.e. the content in confirmation messages were different from Android to iOS) as well as updates to our design system that impacted components we were planning to use in our flow (i.e. changes to our header primary color or spacing within our numpad component). After documenting these updates to be made, I coordinated meetings with the tech teams and product manager to create tickets to update our build, and discuss tech feasibility of contributing a new component to our company wide design language if necessary.
The Add External Accounts feature launched in August 2021 for iOS and early data shows users are successfully using the flow to set up their payments and transfers! Looking back at our original goals, we succeeded in launching this critical banking experience, maintaining product consistency across iOS, Android, & web, and addressing frustration around the delayed verification process for transfer accounts. For additional information on this project, please reach out!