Product Design · Enterprise UX
2026
Standardizing permission-aware account selection at scale
Designing a scalable account selection system that adapts to complex hierarchies, varying permissions, a datasets ranging from 1 to 30,000+ accounts.
Role
UX lead
Team
Design, product, engineering
Timeline
5 months
Industry
Financial services
Context
Project overview
Skip to solution
I led the design of a new account selection experience for BNY’s enterprise reporting product. What began as an enhancement to an existing dropdown evolved into a reusable system designed to support increasingly complex account structures and workflows.
What I did
Created a scalable account selection pattern to be used across BNY's online banking products.
Why it mattered
Existing selection patterns did not support the scale and complexity of BNY's new virtual account offering.
Account structure and identification
Accounts can be physical or virtual, with virtual accounts nested under physical accounts. What users see and how accounts are grouped depends on their permissions.
Users rely on name, number, currency, type, and hierarchical relationships for accurate identification.
Permission-based user types
Instead of fixed personas, users are defined by role and access.
Internal users
BNY teams supporting operational and servicing workflows
Client users
Enterprise treasury teams managing accounts and reporting workflows
External users
Third-party users (such as contractors) with limited or controlled acces
Problem
Understanding user behavior
I spoke with product owners and analyzed existing workflows to better understand user behavior.
Insight
Account selection is a retrieval and validation problem, not a discovery problem.
Users often arrive with externally maintained account lists, known account numbers, and specific accounts they intend to select.
Process
Evolving problem definition
What initially began as a lightweight enhancement to an existing account selection dropdown into a broader systems problem requiring a new scalable selection model.
Solution
Permission-driven rendering: establishing three different hierarchy patterns
Challenge
Users may have access to one, many, or all accounts within an organization
Solution
I established three rendering patterns than adapt account hierarchy visibility based on permissions
Different selection behaviors for varying dataset sizes
Account selection patterns evolved alongside increasing account volume and selection complexity.
01
Bulk selection for large account sets
Intent
I want to quickly select a large externally maintained set of accounts.
Solution
Paste-and-match bulk selection.
02
Search and filter
Attribute-based filtering
Intent
I want to retrieve accounts that share a common attribute.
Solution
Filter accounts by currency, type, or other shared attributes.
Hierarchy-Aware Search
Intent
I want to retrieve a parent account and all associated accounts.
Solution
Searching a physical account returns both the parent and associated virtual accounts.
03
Simple selection
Intent
I want to select a small number of known accounts.
Solution
Dropdown selection.
Takeaways
Key takeaways
This project taught me the importance of designing beyond the immediate use case. What started as a reporting feature evolved into a reusable platform component by focusing on core user needs rather than workflow-specific requirements.
This experience strengthened my ability to balance scalability, flexibility, and consistency in complex enterprise systems.