All mentions of "Apply" were removed from the UI and instead adopted a narrative around "confirming your information", including transparency that we will need an updated credit check.

The term "Pre-approved" had a negative reaction since clients had to do more than simply "accept". We are unable to change that term, so the Primary CTA was changed to "Get started".

A "What to expect" screen was included in the flow to emphasize the concept that we just need to confirm the client's information and ensure this was the best product for them, which directly correlated to Bill-87. Bill-87 ensures clients are provided with banking products that are right for them.

Testing -  Positive reception from users. Users' originally validated our hypothesis that the credit check was not ideal . But they  viewed the bank as "looking out for their best interest" by taking the extra steps to ensure they can handle the responsibility of this credit card. They all said a credit check is to be expected.

In our research we saw clients were less interested in benefits that required a certain spend. They were more interested in benefits that were available immediately with aquisitions. Since this flow needs to be scalable for all credit cards at the bank a clear information hierarchy was implemented, with tangible, readily available benefits to the top.

Testing -  Positive reception from users. Users' liked that they can make an informed decision and equate cost to benefit. They also appreciated looking at features to how it can benefit their day-to-day life.

This required extensive back and forth with business and other parties due to concerns of risk. Created ranges that applied to the various points of approval and had our risk partners validate the solution

Testing -  Positive reception from users. Users' originally validated our hypothesis that the credit check was not ideal . But they  viewed the bank as "looking out for their best interest" by taking the extra steps to ensure they can handle the responsibility of this credit card. They all said a credit check is to be expected.

The technical limitation around the client selecting their preferred location meant that the client would have to select their preferred delivery address before they agreed to the Terms and before they went through the decision process. Therefore, not yet known if the client is approved or not.

To solve for this, the mailing address the client had to review earlier in the flow was used as their default mailing address. The screen to select preferred delivery address was removed from the flow.

The mailing address can now be seen in the final screen. The application number and bank's phone number is also included.

Comparing cards comes up in research all the time. It has been proven that the behaviour in choosing a banking product does not come with loyalty to a bank. It is how much can the user benefit and how little will it cost, no matter the bank.

For this bank offer, we were unable to show a compare feature because only the cards in this flow are part of the "suite of cards" attached to this unique code. Therefore, if a client compared with other cards outside of these three cards, they will no longer be under the "umbrella of the offer code" and currently we have not solved for switching targeted offer codes.

Currently, the bank has ~90% accuracy for eligibility with the original card offer, meaning even the downsell and upsell offer usually see about 10% of the traffic. Due to less accuracy on eligibility for the other cards and sales priority, it was best not to introduce those cards at the start.

In initial testing, users were very confused by the "Upsell scenario", which is a more premium card provided to clients who shared a higher income and/or a better credit score than on record.

Were they still eligible for the original card? Understanding this new path also required learning all about a new product, something they already mentioned in user testing as not being ideal.

Upsell screen acknowledges their approval and visually forces the client to choose - with the use of radio buttons - between the original card or the upgraded card. Clients are able to view the product page, which includes a compare chart for both card options.

Prototype for this experience

Testing -  Users understood clearly that they were approved for two cards. However, users still felt that it was too much expectations to now learn about a new card and they felt rushed to have to make a choice immediately.

For our downsell clients, they were provided a card with lower requirements and not approved for the original. Due to this being a "Pre-Approved" offer we avoided messaging that the bank declined the client.

Technical blockers also applied, since the client had to explicitly select "decline" to not be sent the downgraded card.

The client is required to select a checkbox along with "Accept card offer". If they choose to "Decline card offer" they will be given an alert to confirm their decision.

Prototype for this experience.

Testing -  Users were not the most pleased with this experience. However, data showed that 93% of all clients that came to this page did select "Accept" or "Decline". We also saw that 67% of clients that opened the product page, selected "Accept".