AIB
ROLE
UX Designer (2020-2021)
OVERVIEW
During my time with AIB, I led the design on a variety of projects while working collaboratively with other Designers, Product Owners, Business Analysts, Solution Architects, Project Managers and Developers.
While there, I worked on; the credit card application flow, the log in journey, the primary and secondary methods of Strong Customer Authentication (SCA) for online card payments under the PSD2 directive and before I finished up, I was looking at digitising all the paper forms that are knocking around branches with a view to putting them on multiple channels/platforms and also looking at how customers might seamlessly keep their personal information up to date.
Obviously, each project varied but for the most part I followed an overarching design process; requirement breakdown and determining project scope, primary and secondary research and analysis, concept generation and analysis, wireframing, customer usability testing and analysis, concept selection and prototyping and (once the design was finalised) supporting Developers and QA. The process mentioned here sounds quite linear but of course, it’s not. There's as many backward steps as there is forward ones. Fortunately, it’s in the going back and forth that great ideas are made. That sounds like it should be a Dieter Rams quote but it’s not, that’s all me.
CREDIT CARD APPLICATION (2 WEEKS)
Internal analytics showed that our credit card application flow was being started and not completely finished, for one reason or another, resulting in high levels of contact to AIB Direct (Direct), our contact centre and this needed to be explored. I looked at the current flow and spoke to agents in Direct to gain a better understanding of what was going on. In order to get a credit card, customers must have their PPSN verified by uploading an image of a valid document in the ‘My Details’ section of their account. In the original design, customers were told this on the final screen of the flow only and it seemed as though the information was getting lost. A complete redesign certainly wasn’t needed but visual design and information hierarchy needed improving.
Changes were made in two sections of the flow. In V1, customers were required to input their PPSN as part of the ‘Personal Details’ section, even if they were already PPSN verified. In V2, better backend logic checks the customer’s details and determines what screen to display. If the customer is already PPSN verified, the “What is your PPSN?” text field is pre-populated and cannot be altered, as seen below (left). If the customer isn’t PPSN verified, the “What is your PPSN?” text field is blank and needs to be filled before proceeding. A new note underneath this text field reading; “Once your application has been submitted, you will need to upload an image of a valid PPSN document for us to verify.” was also added to this screen, as seen below (right). Why don’t we verify the customer’s PPSN at this stage? That was a question I had too. Verifying one’s PPSN happens at an account level in the ‘My Details’ section, as mentioned previously. It wasn’t technically feasible to direct customers to their ‘My Details’ section, get them to verify their PPSN and then get them back to where they were in their credit card application journey.
In V1, after the application was completed, customers would be met with the screen below (left) if they weren’t PPSN verified and this wasn’t resonating well with them. This screen blended in too much with the rest of the flow and customers only seemed to be seeing the “Your application has been approved” box. Happy days, job done. Not. Fast forward a week and there was no sign of their new credit card. Confusion. Frustration. A call to Direct. Customers would be informed by an agent at this point that they need to verify their PPSN before we send out their new credit card. More frustration. More time to wait before actually receiving their new card. In V2 below (right), the screen stands out more from the rest of the flow. The title informs the customer that yes, their application has been approved but that they still need to verify their PPSN. The main content of the screen is broken down into more digestible segments, informing the customer what they need to do from here (either right away or later) as well as how and when they’ll receive their new credit card. Overall, the changes detailed here resulted in more full completions (ie. customers verifying their PPSN at the end of the flow) and less calls to Direct.
LOG IN (6 WEEKS)
A customer can log into their AIB Mobile app in three ways; Touch ID/Fingerprint (iOS/Android), Face ID (iOS only) or by inputting their Personal Access Code (PAC). For as long as the PAC has been around in AIB, customers have always been asked to input three random digits in a jumbled up order when logging in rather than the full five digits which they have in their possession. Being that AIB is a bank, security is of the utmost importance always and as part of ongoing security improvements, a decision from the AIB big-dogs was made to move away from the three randomised digits and instead get customers to input their full PAC, in order. From a design point of view, the wheel really didn’t need to be reinvented for this one but there was some big considerations to keep in mind;
- Consistency: There was a few little niggly differences across the Touch ID/Fingerprint, Face ID and PAC screens before this project and that needed to be fixed.
- Communication: For years, AIB have said that they’d never ask customers for their full PAC yet here we are. It’s very important to make customers aware that this change is coming and that it’s legit and not some sort of scam. People always think the worst when something changes when it comes to their bank so comms around this change was going to play a big role.
- Testing: The log in screen is the first screen every Mobile customer sees so it was important to get new designs tested and put in front of customers. Fortunately, there’s always usability testing being conducted by the Design Team and the new log in designs could be included on every prototype that was being tested.
I would’ve liked to do a big redesign of the log in screens and make better use of our pinks, purples and greens - and I reckon that’ll come at some stage - but one step at a time. For now, moving to the full five digits was going to be a big enough change for customers.
If a customer doesn’t have Touch ID or Face ID enabled, they’ll land on the above (left) screen. Quick Balance (one of AIB’s most revered features) can still be accessed as normal and instead of three fields, each labelled with the required digit, they’ll now be met with five unlabelled fields. From there, if the customer taps on any of the five fields, their keyboard will pop up and they’ll be prompted to input their first digit, as designated by a highlighted pink line. In the past, each field was treated individually so if a customer made a mistake they’d have to select and highlight that field before using their backspace button to delete and go back. Not good. In the new design, the fields look separate but they are essentially treated as one. Tapping the backspace button now will simply delete the last digit that was inputted, re-highlight the field and await the customer’s input. As they type, a dot/circle appears and the next field is highlighted. In the previous design, the inputted digits would appear for a split second before changing to a dot which just seems silly to me. Surely that was a security hazard, no? Anyway, we fixed that. Then, once all five digits have been inputted, the ‘Log in’ button becomes enabled and the customer can carry on with whatever banking-bits they want to do.
If a customer has Touch ID enabled, the above (left) screen will be their default landing screen when logging in and if that doesn’t work for some reason, they can tap ‘Use PAC instead’. If they’re still having issues from there, they can then tap ‘Trouble logging in?’ from the PAC screen and follow that flow. All the logic and different possibilities have been catered for. I have all sorts of error states and Android versions of these screens that I could show but I think that’ll get a bit repetitive. What’s cool though (in my view anyway) is that these screens that I’ve designed are seen 20million+ times a month. Not only that, customers have to use Touch ID/Fingerprint, Face ID or their PAC for various in-app verification tasks like confirming payments or detail changes and when registering their device (see below) so these new designs are dotted all over the place. Comms were rolled out regularly in the lead up to these changes being released, informing customers of what to expect and there’s been no major disgruntlements or security worries so happy days says I. During testing too, customers either didn’t even notice the difference on the screens or they did and had no issues so happy days again says I. Overall, the new designs are tidy, consistent, work well and are simple to use.
STRONG CUSTOMER AUTHENTICATION FOR ONLINE CARD PAYMENTS - PRIMARY SOLUTION (14 WEEKS)
Strong Customer Authentication (SCA) is a term that’s been floating around for a couple of years at this stage. I reckon a lot of people would be familiar enough with the term itself because of comms they most likely received from their bank, but I also reckon a lot of people don’t actually understand what it is, which is completely fine.
As per a quick Google search… “SCA is a requirement of the EU Revised Directive on Payment Services (PSD2) on payment service providers within the European Economic Area.” Mouthful. Basically, the way I understand it anyway, added security was needed for online card payments in order to mimic the security of paying for something with your card in person - ie. Chip & PIN. This is an ‘across-the-board’ type situation. All banks who operate within the EU have to abide by these SCA rules. In the later half of 2019, AIB added to the secureness of their Internet Banking log in experience by sprinkling a bit of SCA on there. Every 90 days, AIB customer’s now have to verify themselves when logging into Internet Banking by opening and actioning a push notification we send to their smartphone. That was the first phase of SCA whereas this (online card payments) is the second phase.
Okay, so you’re on a merchant’s website or app, let’s say Amazon. After you’ve popped in your delivery address and card details, you click (or tap) ’Pay now’, or something along those lines. In the past, it’d be job-done, you can carry on with day having completed your online purchase. Now, there’s a couple of extra steps involved. In the new design, after clicking ‘Pay now’, customers will see the below left (desktop) or below right (mobile) screen. We’ll call them the ‘Confirm your purchase’ screens.
At the same time as seeing the above screens, customers will get a push notification sent to their smartphone (below left), which they’ll have to open and action before returning to the ‘Confirm your purchase’ screen and clicking the ‘COMPLETE’ button. I know what you’re thinking. Not ideal. I thought the same, especially when the likes of Revolut are doing things a bit more seamlessly. On Revolut, after you click ‘Pay now’, you get a push notification, you open and action that and when you return to the merchant, the screen has already transitioned to a confirmation type page whereas we require the customer to navigate back and click ‘COMPLETE’. This took me a long time and lots of UX-related, challenge the status quo discussions with senior stakeholders to come to terms with. Unfortunately, the third-party company we were working with on the ‘Confirm your purchase’ screens had some limitations. A call-to-action needed to be in place in order to finish the payment. I really hope down the line that there’ll be more automatic-ness to it but for now, this was the way it was going to work from a functionality point-of-view and it was my job to make the experience as good as possible with the cards I was dealt.
In the “happy path” journey, the customer will follow the above screens. They’ll open the push notification and see the ‘Payment details’ screen. There, they can review the transaction to make sure everything is correct before tapping ‘Confirm’. If they tap ‘Deny’, it’s end of journey and they’re told to freeze their card if they don’t recognise the transaction or give us a call if they’re worried. After tapping ‘Confirm’, the customer will need to input their PAC (or use Touch ID/Fingerprint or Face ID) before landing on the ‘Nearly there’ screen. Customers are told here that their purchase has been confirmed but that they’ll need to return to the merchant’s website/app to click ‘COMPLETE’ in order to be finished. Once they return to the ‘Confirm your purchase’ screen and tap ‘COMPLETE’, they’ll then see the usual payment confirmation screen we’re all used to these days.
Don’t get me wrong, there’s a little bit involved here, with a few places that someone could go astray but, as a journey overall, I’m happy enough. I must have tested 6 or 7 different iterations of these screens with 40 or so customers to get them as good as I could. In my opinion, wording and language and the way information is presented were the most important parts of this project. “Step 1:” and “Step 2:” on the ‘Confirm your purchase’ screen create familiarity with “Step 1:” and “Step 2:” on the ‘Nearly there’ screen. Something which came out a lot in early testing was that customers thought that their payment was finished when they got to the ‘Nearly there’ screen when it wasn’t. They were expecting to receive an email from the merchant, confirming their purchase when in actual fact, they still needed to go back to the ‘Confirm your purchase’ screen and click ‘COMPLETE’ so we needed to make that more clear. Another thing which came up in earlier tests was that customers would immediately click ‘COMPLETE’ on the ‘Confirm your purchase’ screen and wouldn’t read the rest of the content. Now, if the customer does that, an inline error will appear, as seen below (middle) and if customers were confused as to why they were on the ‘Confirm your purchase’ screen in the first place or if they’re having trouble with push notifications, concise accordion dropdowns provide further detail, as seen below (right).
Could this be done better? Absolutely. Having to navigate back to click ‘COMPLETE’ shouldn’t be a step but it is. Overall though, this journey was tested, iterated and dictated by customers and it works. Ultimately, it might be a frustration for customers to have this extra step in their online payment experience but if it makes things more secure and less prone to fraud then every second of the journey is worth it.
STRONG CUSTOMER AUTHENTICATION FOR ONLINE CARD PAYMENTS - SECONDARY SOLUTION (10 WEEKS)
So I’ve detailed the primary solution of SCA for online card payments. The customer receives a push notification, they open that, do a few bits and they’re done. But what about the secondary solution? What if a customer can’t receive push notifications? What then? A fallback was needed and a good ol’ text message and password combo was deemed the right way to go.
In the months and weeks leading up to the impending SCA changes that were on the horizon, various comms were sent to customers in order to make them aware and to help them get prepped. We send messages and emails for this kind of thing but I’ve found in-app notifications to be the most well received. On various occasions leading up to the new SCA requirements, customers were shown the below (left) pop-up/interrupter after they log in. The goal was for customers to have both the primary and secondary solutions set up and this goal was addressed in the pop-up’s messaging. Were customers to tap the button on this interrupter, they would be brought to the ‘Security and access’ section of their Mobile app where they can easily toggle the ‘Push notifications’ switch on, as seen below (middle). If they did that, then that’s them set up for the primary solution I detailed in the previous section above. Easy peasy lemon squeezey. Now, if the customer was really on the ball, tapping ‘Manage’ beside ‘Password for Online Purchases’ would bring them into the below (right) screen where they can begin to get set up for the secondary solution.
Getting set up for the primary solution is as straight forward as you can get in my opinion but the secondary solution has a few extra steps. The aim here was to keep the journey short and simple in order to get set up in as frictionless a way as possible. From left to right below, customers are first asked to confirm their mobile number. Next, they’re sent a 6-digit code in a text message to the number they just confirmed. After that, they have to choose a password. Nothing too fancy, the only requirement in place is that it must be a minimum of 8 characters in length. After confirming their password (a fairly standard practice these days), that’s the customer done. Their Password for Online Purchases which would be used in conjunction with a 6-digit code sent by text is now their fallback solution for confirming online card payments in the event something went wrong with push notifications, the primary solution.
Iterations of the below screens were tested with multiple customers during 4 testing sessions. Any callouts and issues and problems that were raised were identified and rectified in order to create this journey. That sounds like a terms and conditions disclaimer or something. Weird.
If a customer has push notifications enabled, they’ll see the below (left) ‘Confirm your purchase’ screen after clicking ‘Pay now’ or ‘Checkout’ or whatever it might be. I’ve detailed this as part of the primary solution mentioned earlier. If push notifications aren’t working for some reason and the customer clicks ‘Switch to Text & Password’ or if they haven’t got push notifications enabled but they’ve gone through the Password for Online Purchases set-up flow from above, they’ll see the second screen. On this screen, the customer is prompted to enter their Password for Online Purchases. Provided that’s entered correctly and they click ‘CONTINUE’, the customer is then sent a 6-digit code to their mobile which they’ll have to enter on the next screen. Once that’s in and they’ve clicked ‘COMPLETE’, their online card payment is finished. Arguably, this method is even more straight forward than the primary solution. One issue, which is another limitation of the third party we were working with for the ‘Confirm your purchase’ screens, is that customers cannot reset or change their password as part of this flow. If a password is forgotten, the customer is directed, via the accordion dropdowns, to log into their Mobile app or Internet Banking in order to reset their Password for Online Purchases. Not ideal, I know, especially when people are so used to having that “password reset” type functionality available to them whenever a password needs to be entered. Again, like the primary solution, this took me a while to come to terms with but in actual fact, during testing, customers didn’t seem to mind this too much and in actuality, they quite liked being able to manage and store their Password for Online Purchases in their Mobile app.
Overall, between the primary and secondary solutions I’ve detailed, there’s undoubtedly some added friction to the online card payment process but based off feedback, customer engagement and good design practice, the best possible solutions were created in the circumstances.
