Retro: Ally Status Tracker
TL;DR: Ally Bank was experiencing significant call center volume about a single issue users were consistently facing - tracking their wire transfers - and sought to resolve this issue by providing more clarity to users about the progress of their transfer in channels they most frequented. Outcomes included reduced call center volume about this issue, fewer complaints overall about tracking money movement, visibility into other money movement pathways such as check orders, transfers, and deposits, and a scalable component system to add future trackable items to without additional engineering or design rework.
The Problem
For the business
During 2020-2021, Ally Bank tracked trends in call center volume around specific topics, with the goal of identifying key customer concerns that, when addressed, could help reduce operational cost. The team conducting the audit discovered that, of calls associated money movement, the highest volume was about one main user issue: tracking wire transfers. Reducing this volume could reduce call center wait times, allowing call center associates to help more people throughout the day, thus reducing overall operational cost.
Wire transfers were still partially a back-office effort, with some manual steps happening and actual humans being involved.
For the user
Most of the calls about wire transfers were asking about timing in high stress situations - how long would it take for it to go through? Is someone looking at this right now? When will I know that it's complete? Wire Transfers are often used for big money movements - situations like closing on a home, moving large balances from one bank to another, and other hugely impactful life moments. Having confidence and trust that your money is moving where it's supposed to and in the time period it's supposed to is of the utmost importance to users in these moments, and Ally's current setup gave none of that visibility into what was happening within channels users most frequented.
Having visibility into the steps of the process, the approximate timing of the steps, actions to take if something went wrong, and confirmation that everything went right, was a top priority as I delved into finding a solution. I also had in the back of my mind that this visibility wasn't only important for wire transfers, but really for any type of money movement and even some non-money-movement user tasks.
For me (and my process)
A challenge I faced going into this project was that the solution had already been decided on. A Status Tracker, not unlike the Domino's Pizza Tracker (literally - that was the example). This solution had been decided on in closed-door ideation sessions of which design was not a part of. A North Star had been written, principles defined, and solutions even sketched, without design being present.
This presented a unique challenge, as I initially was on board with the idea of a visual status tracker; however, as I learned more about the problem, I increasingly felt like a pizza-tracker-esque visual display was unnecessary to provide visibility to the user. Visibility doesn't always mean visual - visibility can also mean communication. And what I felt the users were really craving here (as exemplified by the sheer volume of calls to the call center for information), was communication.
Additionally, the web team had already designed and shipped a pattern that I was expected to backwards engineer to make sense in our two native apps.
The Process
Discovery
Initial discovery work involved going through call logs to understand some of the user story, learning about the existing wire transfer process, evaluating opportunities for communication within the experience prior to the actual submission of a wire transfer request, exploring similarities between wires and other money movement channels, and conducting a content audit of the existing language used to describe the different phases of the wire transfer process.
There were a few surprises coming out of the discovery work that influenced my next phase of sketching. First was that, in the channel I was solving for (native iOS and Android apps), users weren't able to actually submit wire transfers. But it was the most referenced platform in phone calls to the call center, with users saying "I don't see anything in the app." The app, at the time, didn't even include wire transfers in our reported Bank Activity. Users could only submit and access information about wire transfers from the website. While I knew this, I hadn't fully grasped the disparity in user action and user expectation, and what was actually achievable for users in the moment.
Additionally, another surprise came from the content audit. Language used to describe different phases of money movement, which to the user likely seemed the same, varied. Transfers were submitted or initiated or started, wire transfers were requested, checks were deposited, Zelles were requested or sent. Items were in process or in progress or processing. Money was sent or delivered or deposited or completed. It was not surprising that users found this language confusing and inconsistent. What complicated matters further was that some language was determined by the third party servicer handling some money movement, and labels came directly from their service and thus could not be changed.
Sketching
From what I learned, I had a rough idea of where in the experience information needed to be provided. While I couldn't provide information in the native apps during the actual wire transfer request process, as that functionality was unavailable in the apps, I was able to give users information in the Activity section of the apps.
My initial plan was to communicate more clearly about all in-progress activity, not just wire transfers, and to add a section to the main page ("Snapshot") that included upcoming or in progress activity. I based this idea off existing patterns used in our separate Auto app to track liens, and took some inspiration from other activity tracking experiences in apps like Fitbit, LinkedIn, and MyFitnessPal.
Additionally, I tried to sneak in some more visible access points to common money movement activities in the app, which were currently nested within other menus or several child pages deep into the hierarchy.
I had high hopes and had sketched a few ideas for where in the UI this messaging belonged. My research partner put together a quick validation test to see if I was on the right track.
Seeking Stakeholder Alignment
Because native mobile was following already approved designs and even engineering work done for web, I did not have the luxury of testing an initial set of sketches with users. I went straight from discovery to high fidelity mockups to get directional approval from leadership before putting designs in front of users. I had landed on three conceptual approaches to presenting Status Tracker, outlined in the presentation shown below.
Ultimately, while I felt very strongly that a combination of Opt 1 and Opt 3, with additional supporting access in the nav were the right solution to test, leadership felt that the banners were most aligned to what web had already shipped, were a pattern that already existed, and were the fastest time to get something for native app out in the wild. During this time, I had also learned that we would not be able to implement the banners in mobile as dismissible, and we would not be getting information from the status tracker service during the initial call to provide more information other than “you have a {transfer} that is {status}.”
I’ll be honest - the results of alignment period were pretty devastating. I was convinced that “Recent Activity” was the right approach. Why did one small segment of money movement get special treatment, when all money movement was important to users? Why were we building a special “status tracker” tool that could only ever consume and report on two of the five or so money movement channels we offered? Why couldn’t we just have more comprehensive and cohesive money movement content across all channels. Why couldn’t we just build better communication channels to meet users where they were - push, or sms, or automated calls - to provide transparency in channels we already leveraged?
The native mobile app was consistently treated as second fiddle to web, even though at this time, more users were logging into the app daily and more money movement was being done through the app daily. Users couldn’t even complete a wire transfer in the app and yet we were building a tool to track said wire transfer that could not be managed or troubleshooted through the app.
I was beside myself for a day or two trying to reconcile that this, to me, obvious lack of parity was leading to us building a non-scalable tool. There were several teary phone calls with my director about how frustrated I was about both the research outcomes and the roadblocks being put in my users’ way, of no fault of their own.
Testing
We tested the banners and they performed great in the test. Users were able to find the information quickly, were able to understand the content, and had no complains within the controlled environment of the test.
Animation and Motion Design
While IA and UI work was going on, I also started working on motion design for the actual status bar itself. I learned from a colleague the basics of After Effects, and developed a scheme for determining which version of the status bar was displayed at which stage of the process that worked for every money movement option, not just wire transfers.
The animation used to indicate progress, done in After Effects and present for all money movement, as well as in the feature announcement.
The Solution
While the MVP solution wasn’t what I was hoping for, I was able to convince leadership that this was just a stop-gap to get an MVP out and begin mitigating the call center impact. Status Tracker updates would be included in the fast following Snapshot Redesign project I was also working in on tandem with the wrap up of Status Tracker.
The MVP of Status Tracker, released Nov 2021.
I left Ally before Status Tracker was released, so I do not have data on how the initial phase performed before the Snapshot Redesign project reimagined access to the Status Tracker content.