Transactions: Discovery & Research
CASE STUDY
Josh Hoffert
UX Designer
Research snapshot
Relevant AdvisorHUB hierarchy — simplified
Needs and Tasks
Core insight cards
MVP prioritization and progression
This case study examines the discovery work behind the first step toward introducing transaction data into AdvisorHUB.
As Research Lead, I interviewed advisors, leaders, product partners, and transaction-system experts to understand how advisors use transaction data, where existing workflows create friction, and how AdvisorHUB could begin surfacing that information in a focused, scalable way.
Although the initiative was deprioritized before formal product design began, the research produced a clear problem definition, a set of evidence-based opportunities, and a recommended account-level MVP direction.
Participants discussed many transaction types, systems, and account structures. Beneath that complexity, their work consistently fell into four modes.
I evaluated potential starting points based on advisor value, fit with AdvisorHUB’s existing hierarchy, applicability across financial domains, and the amount of aggregation and normalization each would require.
Account-level recent transactions represented the smallest useful first step. It addressed common investigation needs while building on an existing account context and avoiding the initial complexity of consolidating activity across an entire relationship or book of business.
This progression allowed AdvisorHUB to begin with a focused account-level experience while establishing patterns that could scale upward. Transaction categories, descriptions, status, and account attribution developed for the first release could become the foundation for later relationship summaries, cross-account search, and proactive monitoring.
Context and challenge
Research approach
Advisor needs and tasks
Key research insights
Product architecture
Outcome and reflection
This case study shows:
Participants
Interview
sessions
Financial
Domains
Roles and Perspectives
10
6+
5
3
As Research Lead, I conducted five discovery sessions with ten participants representing advisor management, former investment advisors, organizational leadership, product ownership, and transaction-system expertise.
The research covered transaction workflows across investments, deposits, and liabilities. Participants described both everyday client-service needs and more specialized activities such as cash reconciliation, transaction monitoring, historical research, and exception investigation.
Roles represented
Advisor managers · Former investment advisors · Managers and directors · Regional leadership · Product owner · Transaction-system SME
Domains represented
Investments · Deposits · Lending and Liabilities
Retrieve and communicate
Find historical activity and prepare it for others.
• Research older or closed-account transactions
• Prepare for a client conversation
• Export or organize activity
• Create a clear explanation for the client
Answer a known question about a transaction.
• Confirm whether activity occurred
• Explain an unfamiliar charge or payment
• Determine whether an item was pending or posted
• Identify where money came from or went
Monitor and identify
Explain and verify
Review recent activity to find issues requiring attention.
• Scan previous-day activity
• Identify unexpected cash movement
• Detect fees, overdrafts, errors, or unusual activity
• Find distributions, gifts, or negative cash conditions
Understand how related financial events connect.
• Follow money across accounts
• Reconcile investment income with cash movement
• Distinguish principal from income
• Separate internal accounting entries from client activity
Trace and reconcile
AdvisorHUB ended before the advisor’s work did
AdvisorHUB gave advisors the relationship and account context needed to begin their work, but transaction research required them to leave the product and enter one or more source systems.
The product boundary therefore did not match the advisor’s task boundary.
Evidence: Transaction information was described as spanning multiple systems in 5 of 5 sessions.
Implication
The first transaction experience should preserve the client and account context already established in AdvisorHUB.
Insight 1
Insight 2
The same data supported both investigation and oversight
Some transaction work began with a specific client question. Other work began with advisors scanning recent activity for errors, unexpected movement, or conditions requiring attention.
These modes use much of the same transaction data, but require different entry points and levels of aggregation.
Evidence: Reactive investigation appeared in at least 3 sessions; proactive monitoring appeared in at least 4 sessions.
Implication
Account-level transaction access should support investigation, while relationship- and book-level views can later support monitoring.
Insight 3
Advisors needed aggregation without losing financial context
Participants wanted to review activity across accounts, relationships, or books of business. However, they also relied on distinctions among banking and investment activity, main accounts and subaccounts, principal and income, and internal and external movement.
A single flattened transaction list could consolidate the data while making it harder to interpret.
Evidence: Account, relationship, or book-level context appeared in 5 of 5 sessions.
Implication
Transaction data should be aggregated progressively while retaining account attribution and meaningful financial categories.
Insight 4
Insight 6
Search, filters, and history were essential investigation tools
Advisors searched by amount, merchant, transaction type, check number, account, date, and status. They also needed enough history to investigate activity beyond the most recent statement period.
These capabilities were not advanced enhancements. They were how advisors moved from seeing activity to understanding it.
Evidence: Search and filtering appeared in 3 sessions; extended history appeared in 4 sessions.
Implication
The first release could limit the amount of history displayed, but its data model and interaction patterns should support deeper investigation over time.
Access alone would not make transactions understandable
Participants described inconsistent descriptions, system codes, mixed transaction categories, and internal accounting entries that could resemble client activity.
The usability problem was therefore partly about access and partly about interpretation.
Evidence: Terminology or categorization problems appeared explicitly in 3 sessions, with particularly detailed examples in the former-advisor interview.
Implication
Consistent descriptions, category rules, and distinctions between real money movement and internal activity are foundational UX requirements.
Account transactions
First step
• Recent transactions
• Core transaction details
• Pending or posted status
• Basic filters
• Clear account context
• Drill-down into an individual transaction
2. Relationship activity
Expansion
• Aggregate activity across accounts
• Family, service, and entity summaries
• Cross-account filters and search
• Clear product and account attribution
3. Advisor monitoring
Longer-term vision
• Book-of-business activity
• Exceptions and alerts
• Previous-day review
• Unusual activity and conditions requiring attention
• Proactive client-service opportunities
Where should Transactions be surfaced first?
AdvisorHUB organized client information across family, service, and entity relationships, with financial details available at the account level for investments, deposits, and liabilities. However, the experience stopped before the transaction level. Advisors had to leave AdvisorHUB and access separate source systems to investigate account activity.
This discovery initiative explored the first step toward closing that gap.