CASE STUDY

 Caller Authentication Platform 
The primary goal of the Caller Authentication Platform is to help Service Agents at a bank ensure that callers on the phone are who they say they are and that they have the rights to access the account they are calling about. Functionality had been added onto over time without an overarching design vision, resulting in a clunky and disjointed user experience. New requirements for retail client accounts, as well as new technological integrations, needed to be considered in the new design.

The final design created a distinct hierarchy, dividing information into 3 sections that users could access as necessary.
TIMEFRAME6 months

MY ROLEEnd to end UX/UI Design

TEAMProduct Owner
UX Researcher
Development

DESIGN PROCESSCurrent system analysis
UX Research
Task flows
User flows
Information architecture
Sketching
Wireframing
Prototyping
Usability tests
Project management


    The pre-redesigned application had been added onto over time to accommodate new requirements, resulting in a disjointed experience.
    Identifying Key Issues and Pain Points in the Current Platform
    A survey was sent to 25 users, uncovering the following issues and pain points:  
    • Users stated that critical warning messages for high risk accounts and callers were easily overlooked, resulting in user unease and potential security breaches.

    • Users stated that they often needed to open ancillary apps in order to find critical information needed to complete authentication, such as branch phone numbers, resulting in longer service times.

     Additionally, a review of the app found:
    • Some UI elements and functions were either no longer in use or not integral to the app's core functionality, resulting in a cluttered, confusing experience.
      Creating Separate Caller Journeys to Reduce Missed Warnings
      We discovered that warning messages were not only hard to find but could also be by-passed by users. To address this issue, we identified key use cases and separated them into distinct journeys. This allowed us to not only restrict the options a user could take for each case, but also determine when specific warning messages were needed within the workflow.

      Integrating Key Information Directly Into The Users Workflow
      It also provided an opportunity to place critical information such as instructions and phone numbers from auxiliary apps, directly into each use case journey. Task flows (shown below) were instrumental in identifying the steps for each use case, where they diverged and converged with each other, and established the groundwork for an integrated user flow.
       


      I created task flows of each use case, subsequently used to create new journeys in the app.

      Redesigned User Flow and Sitemap Reveal New Navigation Insights
      With the use cases and task flows in mind, we completely reworked the user flow from the old design and created a detailed sitemap (shown below), providing a comprehensive understanding of how users would navigate through the app. This highlighted the need for corrective measures, as users, being human, could change their minds or inadvertently give the incorrect info.

      A future state user flow shows the complexity of the interactions between the Service Agent and the caller.
       
      Technical Flow Facilitates Usability Discussions with Stakeholders
      A technical flow was developed to better understand how new technology would integrate into the platform, facilitating usability and technical discussions with Product Owners and stakeholders.


      The IVR, an automated authentication system, would push callers into the Caller Authentication Platform at different security levels. A technical flow was key in understanding how it would be integrated, helping to align stakeholders and made visible where problems had come up.

      Integrating Warning Messages and Multi-System Data
      Wireframes were created to explore different possible screen designs and architectures. The interface needed to accommodate a warning message, an authentication workflow, and various supplementary information coming in from different systems. 2 ideas were developed (shown below) and presented for discussion.


      Wireframes showing two directions, the bottom was chosen as it more closely aligned with the experience a user might encounter in other applications on the platform.


      Additional Explorations For Surfacing Incoming Information
      We also explored how new IVR data could be highlighted in a band across the top of the screen. While inclusion of the IVR data was well received in usability tests, we opted for a more streamlined information architecture as the IVR data was only one piece of secondary information that Service Agents would rely on. The result was that all supplementary data was grouped together in the right rail, which would allow users the freedom to to open and close each information block as needed.

      Unused screens exploring how IVR data could be displayed and highlighted.

      Usability Tests Lead to Simplified Designs
      Moderated usability tests were performed with 5 service agents testing the happy path and information hierarchy. Notably, users were confused by the naming convention that had been assigned to each security level, asked for more direct visual feedback when correct/incorrect answers were inputted, and found the addition of next steps and phone numbers embedded directly in the workflow helpful.
      View usability report
      Test screens showing that security levels were hard to understand (top left, left panel), and the modals missing key information (right panel).

      Final Screeens Incorporated Usability Feedback For A Simplified, User-Friendly InterfaceThe final design incorporated the following key features and enhancements:
      • A simple information architecture focusing the user on the main workflow. Content was divided up into 4 blocks: the top for an overall status message, a progress tracker, a large panel on the left for the main authentication workflow, and the right rail for supplementary caller information. 
      • Critical warning messages and ‘Next Steps’ information surfaced at key points in the journey. Key information from auxiliary apps, such as FA and branch phone numbers, was made available directly in the workflow. This, in combination with warning messages, provided users with clear next steps and actionable information, eliminating the need to exit the environment and reducing service times.
      • User-friendly language. RAGB status and technical labeling conventions were replaced with language that was familiar and common to Service Agents.
      • Snackbar messages indicating a caller's status at all times. With the removal of the RAGB status, the large floating message bar in the usability test screens lost much of it’s purpose, security status information was moved into a standard snackbar notification that is present throughout the journey.  
      • A clean, streamlined design that aligns with the current design system.