The World of banking is an interesting one, especially these days and at Mountain America Credit Union (MACU). With new expectations of what the banking experience should be, striving to meet, exceed and innovate those expectations, while staying compliant with compliance changes, there's never a dull moment.
One such project that incorporates all the above mentioned is a redesign and update on Alternative Access Account Management, or, for short: Alt Access.
What is "Alt Access":
MACU previously allowed for an individual to have "Alternative Access" to an account without actually being a signer on the account. Think of it has read-only access. This individual could see what was going on with the account (transactions etc) while not being able to actively use the account. A great scenario for this is a teen getting an account and a parent given the Alt Access to help monitor the account as the teen learns to navigate their financial literacy.
The Problem:
With recent changes in banking compliance and migrating to a new back-end system, it became clear that this Alt Access is no longer a viable option. Anyone who is on an account must be an actual, verified signer on the account. Meaning that if a person traditionally had Alt Access, they either needed to be removed or be given full, signer-based account access. In other words, a joint account holder.
This brings up some major issues - 1) MACU can't arbitrarily remove all those who have alt access. That would cause a lot of panic. 2) Likewise, MACU can't arbitrarily make anyone who has alt access a joint account owner - this would cause issues in that the main account holder may not want that alt person to have full access, and MACU may not have all the proper documentation to allow that to take place regardless. So, we had to give that power to the account holder:
The Process:
We came together with the key stakeholders for this project to go over the issues and come with a solution solve the challenge. We mapped out that when a member logs in (and has people on their account with alt access), they will be presented with a widget explaining what is happening (alt access is going away) and presenting them with the choice to completely remove the access immediately or move to make that person a joint account holder.
Testing:
Due to the urgency of the project, there was some discussion by the stake holders that we should release the widget without any prior testing. This caused a lot of alarm on my team's end, and especially mine. While I have confidence in my designs, I know that testing is imperative to getting things right and working for the end user. My philosophy with design is measure twice (or more), cut once. In other words, we test the designs, then release (hopefully) once. While we had hesitation and some push-back, we prevailed and were able to test. It's a good things we did as while this seems like a simple issues to solve, the language, placing and flow became a bit more complicated than originally assumed.
Design One
On the first iteration, we laid out what we first thought was the right path: A clear, easy to make choice of how the member wanted their account to be accessed by others: Either turn off access (default) or turn it on and make them a joint account holder.
Next in the process is that if the member chose to keep an individual and give them full joint-access, we would need more info. Now, the trick here is that this info is not immediately needed. In fact, it could be skipped completely. We felt this was implied or understandable by making the continue button active without entering any information, along with the third "skip" option. A large portion of this info could be pre-populated if we had it in the system so that it wasn't too overwhelming to the user.
As a last step, we asked users to finalize their choices. The could review what they selected and now move on with their day. We had a final confirmation message letting them know that a rep would contact them to confirm and finalize their request (fill out any remaining info needed that may have been left out). We wrapped it up and gave a round of high-fives that we nailed it. That is until testing...
Welp, mark that down as not successful!
Design Two
Running this through the first round of testing, we got some unfortunate results. Several participants could not figure out the toggle switch and if it was adding, removing or something else entirely. If they made it past the first selection, the next portion of adding joint-holder info was not clear that it was optional and became very overwhelming and frustrating the the user. Exactly what we didn't want. We went back to the drawing board, read the feedback and got to work to improve the design:
This screen was the first to tackle and caused the majority of issues. We had a few more iterations and tested them out, with varying results. Some positive feedback, but again, mostly negative as it felt overwhelming and still unclear. We started again and also worked with our copy writer to ensure the information was clear, concise and simple to grasp.
Design 3
After lots of redesigns and testing, we finally had a widget that was clear and simple. We dumped the confusing toggle switch, cleared up the selections and made the language simple and direct as follows:
The language was precise and spelled out exactly why they were getting this widget. We opted to default to removing access, and if they did change to add, additional information about what they were doing would dynamically appear to avoid any confusion. This tested with a 100% rate of understanding with no negative feedback:
For the next portion of adding account holder information, we cleaned up the language and added a simple "Optional" prompt to let the user know they could skip this part and still continue in the process. This alleviated anxiety and rage quitting.
For the last portion, we cleaned up the messaging, made it clearer of what was taking place and that their selection could be corrected if needed.
In summary:
After the initial round of research, we found that although most participants understood the design, there were opportunities to enhance its clarity. Following design iterations, two additional rounds of research were conducted to address these areas for improvement.
We observed significant improvements in user success and comprehension:
-Overall Prototype Success Rate: Increased from 72% in the first round to 90% in the final round
-Overall Prototype Comprehension: Increased from 78% in the first round to 100% in the final round
Conclusion:
While it seemed simple enough, this turned out to be a fairly complex flow to maximize understanding for the user and ensure that there would be minimal headache added to the backend reps at MACU needing to process all of this information. Through testing, working as a team, iteration and more testing, we released a final product that accomplished the goals of the original request and proved value to several key stakeholders.