is an immigration platform designed to help Venezuelan refugees understand, apply for, and track Temporary Protected Status (TPS) in the United States.
//Role
Senior Product Designer
//Duration
2025 to present
//Context
BNY Mellon | Wove
//Industry
Fintech / Wealth Management
I worked on Model Management as part of the broader investment track I inherited after the previous consulting team rolled off. My work focused on redesigning the core model list experience, improving performance and usability, shaping features like Saved Views and security-based search, and helping position Model Management as the central hub for related actions such as Investment Swaps and portfolio creation.
Problem & Opportunity
The Problem
Portfolio Construction had become fragmented across multiple model types and legacy paths. Wove supported standard advisor models, legacy UMA models, Lincoln CCP UMA, strategy models, brokerage models, TPMs, SMAs, and firm models, but the experience for viewing, editing, copying, and creating them was inconsistent.
Users had to deal with different workflows, different constraints, and different mental models depending on what they were building. That made the product harder to learn, harder to use, and harder to scale. On the product side, it also created duplicated logic and UI divergence between older and newer model-building experiences.
Because this is a live enterprise product used by external firms, the complexity was not theoretical. We were continuously receiving feedback, pain points, and requests tied to real client workflows, which meant the product had to evolve while still supporting many existing states and business rules.
The Opportunity
There was an opportunity to create a more normalized system that could support all of these model types with a shared foundation while still respecting the places where they genuinely differ.
If done well, the experience could become easier to understand, easier to maintain, and easier to scale. It would also strengthen the relationship between Portfolio Construction and Model Management, turning model creation into a more connected and guided part of the broader platform rather than a disconnected set of flows.
Goals & Success Criteria
Normalize model creation, edit, copy, and view experiences across portfolio types
Reduce fragmentation between legacy and newer UMA workflows
Make complex flows easier to understand and navigate
Improve clarity around structure, editability, and next steps
Create reusable patterns that support future development across the investment track
Better connect Portfolio Construction with Model Management and related workflows
Success would be measured through improved usability, stronger internal alignment, better implementation consistency, and a more coherent experience across model types.
Context & Constraints
This was not a clean greenfield project.
I had originally worked on the early drafts, but priorities shifted and the work continued with another team. Later, after BNY Mellon hired me directly and the prior consulting team rolled off, I inherited the broader investment track with my lead designer. That meant stepping back into partially defined work, reconnecting related efforts, and helping create coherence across multiple active projects.
The project also had substantial complexity:
multiple model types with different rules, permissions, and constraints
legacy and new UMA experiences that needed parity without becoming identical
tight integration with Model Management and related features like Investment Swap
continuous client feedback from firms actively using the product
ongoing iteration rather than a one-time launch
heavy data density, hierarchical views, linked accounts, risk logic, disclosures, exports, and validation states
Portfolio Construction also became increasingly connected to a broader platform direction where model creation would be launched more contextually from Model Management rather than treated as a fully separate destination.
Users & Research
Target Users
The primary users were financial advisors and portfolio managers creating or managing models inside Wove. Secondary users included internal operational and product teams who needed consistency, scalability, and clearer downstream behavior across the platform.
Research Approach
Before I took over the project directly, user research had already been conducted around UMA portfolio construction. That work focused on how advisors think about building portfolios, what they need to see while constructing them, and how they expect to act once a model is finalized.
After I inherited the work, the project became a continuous design effort shaped by:
earlier research findings
ongoing client feedback
recurring reviews with product owners
close collaboration with engineering as requirements and edge cases evolved
Key Insights
Users wanted a portfolio construction flow that felt simple, detailed, and intuitive
Advisors thought about UMAs holistically around client goals, not just allocation mechanics
Many users preferred starting from an existing model, strategy, or template rather than from scratch
Users needed clearer signals around what was editable, what came next, and what finalization actually unlocked
Aggregate and hierarchical views were often easier to understand than sleeve-only views
Creation options could feel overlapping or redundant if not framed clearly
Downstream actions like analytics and account-level implications needed to feel more connected to the creation process
Problem Statement
How might we create a normalized portfolio construction experience that supports multiple model types, preserves complex business rules, and still feels clear, intuitive, and scalable for advisors?
Strategy & Approach
The strategy was to separate what should be shared from what needed to stay specialized.
Instead of treating every model type as its own product, we designed a common foundation for create, edit, copy, and view states while allowing different model types to branch only where their business rules required it. That meant building consistency around naming and metadata, hierarchy view selection, allocation tables, left-panel summaries, linked accounts, analytics access, draft and finalize actions, and export and audit trail patterns.
From there, model-specific rules could layer on top. Legacy UMA, Lincoln CCP, strategy, and brokerage models all behaved differently, but they could still feel like part of the same system.
Another major part of the approach was reducing ambiguity. The work was not just about making screens look cleaner. It was about helping users understand what they were building, what was allowed, what had changed, and what would happen next.
Information Architecture & Flows
The information architecture had to support both consistency and variation.
Portfolio Construction needed to support:
standard advisor model creation
legacy UMA build-by-sleeve flows
Lincoln CCP UMA flows
strategy model creation
brokerage model creation
TPM, SMA, and firm model views
edit states with current versus new comparisons
downstream connections to linked accounts, analytics, and model details
A major part of the IA work was normalizing how users moved through create, edit, and view states regardless of model type. This included consistent top-bar controls, hierarchy switching, side-panel summaries, footer actions, and table structures.
The newer platform direction also strengthened the relationship between Portfolio Construction and Model Management. Instead of treating creation as a separate island, the longer-term direction moved toward launching portfolio creation from Model Management through guided, contextual entry points.
Design System & Visual Direction
The work was grounded in Hamilton, BNY Mellon’s design system, which I also helped build and expand.
That mattered a lot here because Portfolio Construction needed more than polished screens. It needed reusable patterns that engineering could implement consistently across a large number of related surfaces. I had already worked on Hamilton components and specs for items like accordions, calendars, empty states, and other reusable UI, so I was able to apply that systems thinking directly to this work.
The visual direction emphasized:
clear hierarchy in dense data environments
stronger distinction between editable and read-only states
reusable panel, drawer, and modal patterns
cleaner allocation views
more consistent table behavior
scalable patterns across many model types and edge cases
The work was designed at high fidelity and aligned closely with implementation needs, which made collaboration with product and engineering more direct and practical.
Wireframes to Prototype
This project evolved through a long iterative process rather than a single clean handoff. I first contributed to the early drafts, then later returned to the work once the investment track was reassigned. From there, my lead designer and I met regularly with product owners throughout 2025 and into ongoing work, refining requirements, adjusting flows, and responding to client needs and engineering realities.
The work ultimately moved into high-fidelity design across a large number of connected screens and states. For more complex workflows, I also used prototypes to validate logic and interaction patterns before implementation. In Portfolio Construction, I built a prototype for the UMA experience to help test and align on more involved actions and transitions, especially in areas where business rules and user behavior could quickly become confusing.
Because of the breadth of the system, even relatively small changes often had to be reflected across many related pages, model types, and states at once.
Usability Testing & Iteration
The earlier research had a strong influence on the product direction, and the work continued to evolve through regular refinement and feedback.
Problem: Entry points and creation methods could feel overlapping
Solution: Clarified how different creation paths were described and structured so users better understood which route fit their goal
Problem: Users often preferred to begin from an existing model or template
Solution: Treated model building more like a guided and reference-based workflow, not just a blank-state exercis
Problem: Sleeve-only views were not always enough to support decision-making
Solution: Strengthened aggregate and hierarchical views so users could understand overall allocation while still drilling deeper
Problem: Users were unsure what was editable and what happened after finalizing
Solution: Improved state clarity, guidance, and downstream flow understanding
Problem: Business rules varied widely by model type
Solution: Built shared patterns where possible, then layered model-specific constraints only where necessary
Outcome & Impact
Portfolio Construction became a foundational normalization effort across the investment track.
The work created a clearer and more reusable experience model for portfolio creation and model viewing across multiple product types. It also gave product and engineering a stronger foundation to build from as the investment ecosystem continued evolving.
Because this is an active enterprise product, the impact was not a one-time launch. The work continues to support ongoing delivery, refinement, and client-specific iteration, while helping the broader platform move toward a more connected relationship between Model Management and model creation.
Reflection & Learnings
Challenges
Inheriting partially developed work and bringing it back into a coherent system
Aligning multiple product owners, engineering dependencies, and related tracks over time
Designing one normalized experience across several model types with genuinely different constraints
Balancing deep financial detail with the simplicity users expected
Supporting live client needs while still improving system-level UX
What I Learned
Normalization work is as much product strategy as it is UX design
In complex fintech tools, clarity around next steps and editability matters as much as layout
Shared patterns only work when they respect real business differences
Active enterprise products require designing for ongoing change, not just for launch
Tight integration between hub experiences and creation flows can reduce cognitive load significantly
Next Steps
Continue integrating Portfolio Construction more tightly with Model Management
Further simplify and clarify creation entry points
Expand downstream support after finalization
Validate newer normalized flows with additional user feedback
Continue extending reusable patterns across the broader investment track
