Two-Factor Authentication (2FA)

The client was a member-owned bank that works with member financial institutions. The goal of this project was to retire physical tokens and use phone-based tokens for authorizing transactions on a banking portal.

Due to confidentiality agreement, I generalized the content. 

Problems: 

• It’s cumbersome for users to carry physical tokens, especially when traveling

• It takes 1.5 to 3 days to mail physical tokens to users

• There is administrative overhead with activating, synchronizing, and recovering tokens
  

Solution: Phone based “soft” token that meets security guidelines and reduces administrative overhead

My Role as the In-House UX Designer:

• Analyze user journeys & conduct competitive analyses

• Ensure design works with technology approved by information security

• Pitch proposals and get stakeholders' buy-ins, e.g. Audit, Legal, IT

• Create wireframes following existing design guidelines

• Document requirements in Confluence and create Agile stories in Jira

• Plan transition activities, such as facilitating email address updates, announcements, reminders, phased roll-out strategies, and training material for support teams

• Provide production-ready icons as well as code (HTML and CSS) for new components

User Roles in the System:

• “Access Manager” at member institution, who manages user emails and passwords

• “Signers” at member institutions, who need 2FA to authorize transactions

• Audit users at member institutions, who need regular reports of who has what access

• Internal Bank support team, who helps members to troubleshoot
  

Research Current System and Technology Limitations: I interviewed support team members who issue and mail tokens to understand the current flow. In addition, I discussed with development and security teams about the functionalities and limitations of the to-be-approved third party applications. Sample constraints:

• Signer’s email addresses in the system are managed by “Access Managers” (role) at member institutions

• The approved authorization application can only send a verification code via text, phone, and app, not email. The phone call option does not work with extensions.

Competitive Analyses: I examined how other commonly used applications implement 2FA, such as Google, Facebook, and various banking applications, because our users likely have mental models based on them.

Flow Diagrams and Wireframes: I outlined workflows in Draw.io, sketched wireframes in Adobe XD, animated them with InVision, and presented the clickable wireframes to stakeholders, e.g. IT and Legal.

Challenges: Below are a few examples of challenges I identified and found solutions for

• Phone numbers with extensions cannot receive authentication code.
  Solution: After exploring feasibility with lead engineer and assess potential impacts, I altered the page to not accept phone number with extensions, worked with content strategist to update instructions “direct line only, no extension”, and updated team training material.

• Email addresses on file are required to set up 2FA, but the emails may not be accurate
  Solution: I collaborated with the Marketing department to design email campaigns, asking Access Managers to update emails at their institutions. Moreover, I spearheaded a phased release plan which allowed us to identify and resolve issues before the full launch.

• Activation link in email is session and browser dependent.
  Solution: We updated the language to “[...] copy / paste the link into the same browser from which you requested access.”

Hand-off and HTML Prototype: I shared the XD wireframes with developers, created icons, as well as interactive HTML templates for new components that were not part of existing design guidelines. I also provided training for team members who interact with users, so everyone is aware of the flow and answers to frequently asked questions.

Reception: The changes were well received by members and reduced token issue time by 99%. It also eliminated physical tokens (approximately $80,000) and lessened administrative overhead (approximately 1000 man hours per year). Moreover, we were able to train the Bank support team on how to handle anticipated issues (e.g. members who only have access to phone numbers with extensions) and had a smooth transition.

Learnings:

• Individual roles have different needs. Member institutions (customers) are not users.

• Always list out and double check assumptions, such as assuming emails are up-to-date.

• Careful examination of user journey can uncover user experience issues up- and down- stream of interface design.

• For project releases that require customer support, consider phased rollouts.