Product design, financial services

2026

Standardizing permission-aware account selection at scale

Standardizing permission-aware account selection at scale

Standardizing permission-aware account selection at scale

Designed a scalable account selection system that adapts to complex account hierarchies, varying permissions, and datasets ranging from 1 to 30,000+ accounts.

Overview

TreasuryEdge is an enterprise platform used by clients to manage accounts, payments, and reporting. Within the reporting experience, users needed a way to accurately identify and select accounts across increasingly large and complex datasets.

Role

Lead UX designer

Collaborators

Design, product, engineering

Tools

Figma, Miro,
Magic Patterns

Timeline

5 months,
Jan-April 2026

Background

Defining 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 (ex. contractors) with limited or controlled account access.

Account structure and identification

Users can have physical and/or virtual accounts. Virtual accounts act as child accounts, sitting under a parent physical account. There can be one, many, or no virtual accounts under a physical.

Within reporting workflows, users rely on account name, number, currency, type, and hierarchical relationships to accurately identify accounts.

Account visibility varies based on user entitlements, which results in three hierarchy patterns: semi-grouped, grouped, and flat.

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.

Problem Statement

Users needed a way to quickly and accurately identify accounts across increasingly large and

complex datasets.

User need

Quickly identify and select relevant accounts across hierarchical structures

Business need

Support consistent account selection across growing datasets and workflows

Solution

Permission-Driven Rendering

Different entitlement models required three rending patterns: grouped, semi-grouped, and flat.

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 that adapt account hierarchy visibility based on entitlements

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.

Process

Design Approach

To quickly validate complex behaviors and edge cases, I used AI-assisted prototyping as interactive wireframes to align with product and engineering early in the design process.


Once aligned, I translated approved patterns into high-fidelity designs and reusable system components in Figma.

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.

Version 0 (legacy)

Existing Dropdown

Challenge

Built for small account sets and physical accounts only.

Response

Simple dropdown with account numbers only.

Version 1

Adding Account Identification

Challenge

Users needed additional identifiers to distinguish accounts.

Response

Added account name and currency to improve recognition.

Version 2

Scaling Beyond Dropdowns

Challenge

Increasing account volume and virtual accounts made simple dropdowns difficult to use.

Response

Introduced searchable table patterns, larger selection areas, and selected/all states.

Version 3

Supporting Hierarchical Accounts

Challenge

Users needed visibility into relationships between physical and virtual accounts.

Response

Introduced grouped, semi-grouped, and flat hierarchy patterns.

Version 4 (final)

Supporting Large Account Sets

Challenge

Manual selection became inefficient at enterprise scale.

Response

Added paste-and-match bulk selection workflows.

Version 0 (legacy)

Existing Dropdown

Challenge

Built for small account sets and physical accounts only.

Response

Simple dropdown with account numbers only.

Version 1

Adding Account Identification

Challenge

Users needed additional identifiers to distinguish accounts.

Response

Added account name and currency to improve recognition.

Version 2

Scaling Beyond Dropdowns

Challenge

Increasing account volume and virtual accounts made simple dropdowns difficult to use.

Response

Introduced searchable table patterns, larger selection areas, and selected/all states.

Version 3

Supporting Hierarchical Accounts

Challenge

Users needed visibility into relationships between physical and virtual accounts.

Response

Introduced grouped, semi-grouped, and flat hierarchy patterns.

Version 4 (final)

Supporting Large Account Sets

Challenge

Manual selection became inefficient at enterprise scale.

Response

Added paste-and-match bulk selection workflows.

Curveball ⚾️

I had to switch design systems!

Version 0 (legacy)

Existing Dropdown

Challenge

Built for small account sets and physical accounts only.

Response

Simple dropdown with account numbers only.

Version 1

Adding Account Identification

Challenge

Users needed additional identifiers to distinguish accounts.

Response

Added account name and currency to improve recognition.

Version 2

Scaling Beyond Dropdowns

Challenge

Increasing account volume and virtual accounts made simple dropdowns difficult to use.

Response

Introduced searchable table patterns, larger selection areas, and selected/all states.

Version 3

Supporting Hierarchical Accounts

Challenge

Users needed visibility into relationships between physical and virtual accounts.

Response

Introduced grouped, semi-grouped, and flat hierarchy patterns.

Version 4 (final)

Supporting Large Account Sets

Challenge

Manual selection became inefficient at enterprise scale.

Response

Added paste-and-match bulk selection workflows.

Reflection

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.


The experience strengthened my ability to balance scalability, flexibility, and consistency in complex enterprise systems.

Like what you see? Let's connect.

© Rebecca Skier 2026

Created with love, Framer, and lots of caffeine.

Like what you see? Let's connect.

© Rebecca Skier 2026

Created with love, Framer, and lots of caffeine.

Like what you see? Let's connect.

© Rebecca Skier 2026