Wealth Hub - AllianceBernstein
Providing users with the ability to aggregate and view finances across all institutions in one place.
SUMMARY
The Need
AllianceBernstein is a global research and investment management firm with institutional, retail, and high-net-worth investors. Our cross-functional team, User-Centered Research & Design, works with AB’s private clients to design features for our mobile app and web. The team was comprised of 2 iOS developers, 2 UX designers, a UI designers, 2 QA associates, and a project manager. We were tasked with creating a mobile and web feature called Wealth Hub, with a goal to give clients the ability to bring in external financial account information into our app so that they could get a view of their total net value.
BACKGROUND
Reasons & Objectives
Wealth Hub was one of our business stakeholder’s top priorities during the end of 2018 and start of 2019 due to requests from both AB’s private clients and financial advisors. The goals, beyond giving clients this total net value view, was to draw clients towards using our technology as well as giving our advisory teams a more transparent look at their clients’ outside accounts and assets. We decided to work with a third party aggregator, Quovo, to handle the adding and editing of external accounts.
The Role & Responsibilities
Assist with exploratory user research and competitive analysis
Design, wireframe, and prototype the app and web user experiences
Conduct usability testing for the app and web and iterate on feedback
Write the business requirements document and liaise with front and back end developers to work out technical specifications
Lead intra and inter team meetings to discuss designs, business requirements, technical needs, legal constraints, and information security risks
RESEARCH
Summary
As we began this project, we thought it necessary to interview both in-house financial advisors and our clients because both parties had requested and would be using the feature upon release. We conducted the interviews with advisors and assisted another designer on the team with client interviews. We also met with senior leaders and business stakeholders to discuss needs and requirements. Finally, we conducted an informal analysis on some competitors’ wealth aggregator tools and reviewed Quovo’s constraints.
Financial Advisor Research
We met with 5 geographically dispersed advisors to gain understanding about their desires, their perceived clients needs, and their current state. What we found was:
Most clients have no problem sharing their total financial net worth with their advisory team but advisors most often do not have current, or any, physical copies of external account information
Few clients are already enrolled with Addepar, another third party aggregator, through AB. But, they use it most often to get a deep dive into their investment funds rather than to see their total net worth
Several advisors believed that clients would be hesitant about the security of information within an Wealth Hub feature as well as the privacy of specific external account information from their advisors
Client Research
A lot of what advisors said was echoed by the clients we interviewed. Many clients showed interest in the convenience and accessibility of the Wealth Hub feature, with a few hesitations:
Most clients keep track of their total net worth on their own - often times using an excel spreadsheet or pen and paper
Clients are worried about the privacy of external account information and what their AB financial advisors will do with it
In parallel with advisors, many clients say that they’re comfortable discussing their outside financial information with their advisors
Before sketching initial designs, client journey and empathy maps were drafted:
Quovo’s Constraints
Using Quovo posed design difficulties as we thought about designing the feature. The biggest constraint was that Quovo only allowed the deletion of an entire institution (e.g. Chase Bank) rather than individual accounts (e.g. Chase Bank checking account or Chase Bank savings account). Designs had to be made so that if clients did not want all accounts within an institution, they could still “remove” them from their aggregated view on our app without technically being able to do so on our back-end. Designing for this constraint requiring collaborating with Quovo’s resources, our back-end developers, our front-end developers, and legal and info-security teams.
DESIGN PROCESS
Pivoting Based on User Feedback
After initial user research and competitive analysis, the wireframes we drafted organized external account information by institution (e.g. Fidelity, Schwab, etc) rather than by category of asset or liability type (e.g. cash, credit, investments). However, a look at competitors coupled with a first round of usability testing and a card sorting activity revealed that clients tend to view their finances in terms of assets and liabilities rather than grouping accounts by their parent institution. Thus, we iterated on the core screen of our design from what you see on the left to what you see on the right:
Iteration Sketching
Following the first round of usability testing, we began sketching and iterating in collaboration with the user interface designer on the team. We took a lot of inspiration from the Mint app, but had a challenge their designers did not in that Wealth Hub is just one feature amongst many on our app. In fact, it’s one that we estimate many of our clients will not choose to engage with. Thus, we had limited real estate on our app to design all the necessary features of Wealth Hub. Whereas Mint puts account within its home tab and allows users to manage their connections in the Settings tab, we needed to display all the important financial information as well as allow access to managerial settings within one tab. We played around with multiple ways to visualize our clients money, their institutions, and ability to edit in the sketches below:
USABILITY TESTING
Intro to the Prototype & Testing
The design used for the next round of prototyping included an overview page displaying all accounts grouped by asset and liability type; clicking on an account itself displayed the institution that account fell into as well as the other accounts within that institution. Here, users could remove the institution, edit login, or manage settings for accounts. As this information architecture was vastly different from the first design, the UI designer and I went into our usability tests wanting to know if the flow between screens and the actionability of buttons made immediate sense to users. Were our designs clear, or did we need to tweak architecture, interactions, copy, or visuals?
Results
The usability testing revealed a pattern among most clients — they did not expect that clicking on an account would bring them to that account’s institution screen. Instead, they expected to see something like transactions or holdings for that individual account. Not only did they not expect it, but they were mildly confused by this flow. They either didn’t connect that the screen was the complete institution and not just the account itself, or couldn’t make sense of the Remove and Edit Login buttons on the screen. Several users commented that the flow wasn’t very intuitive to them. We combined the most relevant feedback into an affinity diagram to help me distill the findings and iterate on the designs:
Changes
Besides making several small copy changes due to confusion and reordering asset and liability types based on card sorting results, we focused on designing an altered information flow for the feature. We needed to give users the ability to manage all their connected institutions as well as well as give them a view of all their accounts grouped by category. Instead of trying to send users from account to institution, we made a Manage screen to house all institutions in one view. The accounts themselves were no longer clickable; users expected a click to send them to transactions and the business required that we didn’t include those in our MVP. We added a Manage button to the asset overview screen so users could view and edit all institutions and accounts. The required functionality still existed, but with an information architecture that was more intuitive to users.
CONCLUSIONS