Business Banking financial health quiz
the Opportunity
Sales and relationship deepening
Branch Bankers at Huntington are using disparate collateral to recommend products, services and accounts to business banking customers. They are also unsure of how and when to deepen relationships, when to sell and how to keep the conversation going. Finally, there are services specifically catered to the small to mid-size business market that are new to the bankers and can create complex decision making and recommendation calculations.
Agile Delivery Model
While navigating this complex problem space, our team stood up agile pods. This was Huntington’s first major attempt at Agile and was implemented through this project as a part of a larger OMNI initiative. Business Banking Financial Health Quiz (BFHQ) was the highest priority and most complex product in the backlog.
The Process
Mapping it out
Due to the immaturity of the agile process, the user stories had been created solely by the business unit. To start visualizing the flow I laid out very simple, low fidelity wireframes. I started with pages that already existed in our salesforce experience. I then organized the user stories into themes which would become pages. I noted pages that were out of scope (outlined in red) and user stories that had issues.
The stories with issues had one of the following problems:
The story was too complex and needed to be broken into several
The functionality didn’t make sense
The story was poorly written
I then consulted with Salesforce developers to find out what modules would be achievable in our timeframe and created very high level wireframes.
wireframes and review
During working sessions I sketched out ideas in my notebook to make sense of all of the conversations. I created wireframes in Axure to review with the project team. This allowed everyone to easily see how the user stories could come to fruition. It provided a mechanism for architects, developers and business owners to raise any issues and verify that the functionality was appropriate and possible.
By taking this step, I uncovered some nuance in the way the calculations worked. It became clear that the addition of certain services could change the recommendation of deposit products. Concerns were also raised by the lead architect, who was worried that a piece of the functionality would cause frustrating delays and we might want to rethink the approach.
Tech considerations
Many technical considerations come into play when working with disparate systems and banking regulations. Salesforce had been chosen as our CRM before the project began. Our calculations for recommendations could not be done locally, because of security concerns. The way Huntington’s tech stack is set up causes these calculations to be passed through Service Oriented Architecture (SOA). Due to this, the architect was worried that the many successive calculations that could potentially be performed would frustrate the banker and customer. There is also a limit of service calls we can make in any given system in a timeframe. This, however, was expected to be moot due to the lower volume of business clients.
Logic Complexity
There are several distinct pages in BFHQ. Their purposes are to get to know the customer, tell them about services that may benefit their accounts, and recommend deposit accounts and credit cards. The experience can also create opportunities and referrals for the banker or other bankers. The business unit defined many interdependencies which required recommendations to be driven by many different factors and created opportunities to change metrics on the fly. These considerations drove ideas like a “scoreboard” that would allow users to update previous page information from anywhere in the experience, and pulling the services page earlier to let it drive checking recommendations.
Testing
Working with one of our UX researchers, I created key questions and a testing plan for 10 branch bankers working in the field. We found that based on this small sample, the bankers preferred:
Waiting on a delay, instead of using a “calculate” button.
Breaking Available Services questions into a different page.
Displaying a floating calculator, deemed the “scoreboard” on all pages for easy edits to responses, which can drive different recommendations.