What I did

Research & Personas

Conducted 10 user interviews across performance, fixed income, and client reporting teams to understand how radically different user needs were — from daily power users wanting deep configurability to executives expecting fully packaged views. This research directly shaped six personas and the platform's core design strategy.

Design System (from scratch)

Studio's design system was built from the ground up — establishing tokens, components, and patterns for a data-dense, multi-tier platform from day one.

Ownership & Scope

Studio was built by a larger design team. I owned three core areas — Discovery, My Workspace, and Monitor — designing the end-to-end experience for how users search and configure model output, manage their own data and models, and receive packaged views without direct system engagement.

Data Studio is an internal analytics platform for a global financial services firm, built for teams across performance, fixed income, and client reporting to work with multi-variable investment model output. I designed the platform from scratch — conducting 10 user interviews to build out six user personas spanning daily analysts to executive stakeholders — and led the core Discovery, My Workspace, and Monitor experiences, along with the design system behind them.

BNY Mellon's financial teams relied on an old third-party system to work with complex investment data. It was outdated and hard to maintain, and the company decided to replace it — potentially building something new in-house instead. That new platform became Studio, and it needed to work for the entire company.

The challenge was that people used the system very differently. Some people worked in it every day, doing deep, detailed analysis, and needed speed and control. Others — like team leads and executives — barely touched the system directly, but still needed full visibility into the same information, delivered in a way that took almost no effort on their part. A single, one-size-fits-all design would fail one of these groups. Studio needed to work for both.

Business Context & Problem

Old system the team was using: difficult to scale, lacks crucial capabilities.

Replace the legacy system with something that worked for everyone using it — not just power users or just executives. Specifically:

• Give daily users the speed and control they needed to do complex analysis without extra friction

• Give executives and team leads full visibility into the same data, with no setup or manual digging required

• Build a design system strong enough to support a large, data-heavy platform used company-wide, from scratch

Objectives

There were two very different relationships to the same data.

Research & Insights

To understand who'd actually be using Studio, I conducted 10 interviews across the teams the platform needed to serve — performance analysts, fixed income specialists, client reporting managers, and leadership. These interviews shaped six user personas, from people who'd be in the system every day to executives who'd barely touch it directly.

A few things came out clearly:

Power users — daily analysts — wanted deep control and hands-on access, but also wanted to spend less time on maintenance and more time actually analyzing. Executives and team leads, on the other hand, barely wanted to log in at all. Several of them described almost the exact same need, independently: everything should be "packaged and handed to them," requiring little to no effort on their part.

The things executives actually cared about were narrow but consistent.

Across multiple interviews, the same few needs kept coming up: being notified when something needed attention, being able to monitor things at a glance, and having a clear record of who did what — comments, audit trails, accountability — without having to dig for it themselves.

Requirements weren't always fixed yet.

Some needs, like reporting standards tied to industry compliance, were still evolving during the research — which meant the system needed to be flexible enough to accommodate things that weren't fully defined at the time.

Personas

Francesca

"I need to be able to create, edit, and approve workflows made by others, because I am responsible in my firm for this."

"I need to see if there tends to be failures, missed deadlines, etc in specific workflows so that I can change how the workflow is being handled by my team."

Edward

"I need to see what factors drive performance, since these help me decide what made us successful."

"I need to be able to determine if the data we have is fit for purpose, so that the people working on Analysis have the best tools available."

Research shaped six personas in total, spanning the full range of people who'd use Studio. Here are two that show the clearest contrast: Francesca, Head of Performance, who works inside the platform daily and manages a team through it; and Edward, the CIO, who barely logs in but still needs complete visibility into what's happening. Together, they capture the core tension the design had to solve — depth and control for the people doing the work, versus zero-effort clarity for the people overseeing it.

Discovery is the platform's search and exploration space — where users find the material they need to inform a decision or build into their own work. It pulls together several very different content types in one place: datasets, visualizations, news, research, scenarios, presentations, and recorded calls and transcripts. Some of this content comes from inside BNY Mellon itself — internal calls and research, for example — while other content, like certain datasets, comes from outside vendors and data suppliers. Users can search across all of it, or filter by things like category, canonical group, and certification status, to narrow down to material they can trust and actually use.

Visualizations alone cover several different formats — charts and graphs, advanced tables, HTML components, dashboards, and full applications — because different tasks called for different ways of looking at the same underlying data. A quick trend check needs a chart; a detailed audit needs an advanced table; a recurring report needs a dashboard someone can return to.

"Discovery"

While most people touched Discovery at some point, it was used most heavily by the power users — analysts and specialists making high-stakes financial decisions day to day, who needed to move quickly across large amounts of material without losing precision.

My Workspace is where users manage the data that actually belongs to them — datasets bought or shared with them by the organization, plus the visualizations, scenarios, portfolios, watchlists, and bookmarks they've built or saved. Everything here is something they can act on directly.

For datasets, users can view the full data, filter it, and use an "Analyze" option to turn a plain table into a chart, graph, or other visualization — either from a template or from whatever they've currently got selected. They can also add new data themselves, either by building a new data model from scratch or importing one from the company's shared data catalog.

"My Workspace"

On its own, a single model shows a specific, fixed result. But financial decisions rarely come down to one number in isolation — analysts need to compare models against each other to understand what's actually driving a result, and to make better predictions. My Workspace's visualization builder is where that happens: creating a new visualization takes users into a dedicated working environment where they can pull in different pieces — dates, assets, or entire models — and combine them into one view. A common pattern was layering a benchmark model (shown as a reference line) against other data pulled from different models, so users could directly compare characteristics side by side rather than looking at each model in isolation.

Connecting models

Early versions of the roadmap treated "connecting models" as a nice-to-have feature. Research with power users showed otherwise — a single model's output in isolation wasn't especially useful to them; what they actually needed was to compare models against each other to understand what was really driving a result. That insight elevated model-connecting from a minor feature to one of the platform's core initiatives, and shaped the visualization builder described above.

Monitor was built for the personas who wanted the opposite of Discovery and My Workspace — no setup, no digging, just a clear picture of what's happening. Edward, Francesca, and Betty all described versions of the same need: everything should be visible at a glance, without them having to go looking for it.

The core of Monitor is a timeline view of selected models, dashboards, and saved views, showing whether everything is running normally or something has failed or hit a technical interruption. Users can filter that timeline by warning severity — critical, major, or success — as well as by data vendor and by when an issue occurred, so someone checking in briefly can quickly narrow down to what actually needs their attention.

"Monitor"

Notifications inside Monitor cover two different kinds of signals: errors and warnings — flagged with a yellow "something to be aware of, though not necessarily broken" indicator — and updates, which cover collaboration activity, like someone requesting an edit to a model, application, or visualization. This meant Monitor wasn't just a health check on the data itself, but also a way for oversight users to stay aware of what their team was doing, without having to be inside the platform daily.

This covers the version of Monitor built around data performance during my time on the project. A later iteration added dedicated Events and Activities sections, which I wasn't involved in designing — worth a brief mention for completeness, but outside the scope of what I can speak to in detail.

Challenges

Bridging the gap between expert knowledge and plain requirements

The people using Studio were deeply skilled in finance, but often struggled to describe what they actually needed in plain terms — they knew their work intimately, not how to translate it into a design problem. This meant I couldn't just take requirements at face value. I had to dive into the subject matter myself — understanding what people were actually doing and why — before I could design something that felt genuinely useful rather than technically correct but disconnected from their real workflow.

Designing within existing technical constraints

Some of the platform's core capabilities — creating new models, building new visualizations — were already built on specific existing technology before I joined the project. That meant constantly balancing what I believed would create the best experience against what the current development approach could realistically support, and finding workable middle ground rather than designing in a vacuum.

Staying consistent across a distributed team

Studio was built by a larger design team, with different people owning different areas of the platform. Keeping Discovery, My Workspace, and Monitor consistent with each other — and with the rest of the platform — meant constantly checking my decisions against a system I didn't fully control alone.

Design System

I started building Studio's design system back in 2021, when Figma's own capabilities — especially around variables and shared libraries — were far more limited than they are today. Even without today's tooling, we set up a proper foundation: components and styles lived in a shared Figma library, documented in ZeroHeight, and mirrored in Storybook so design and development stayed in sync.

This wasn't a solo effort. Other designers on the team were building against the same system, so we held regular design system sessions to review new components, catch inconsistencies, and keep the library up to date as the platform grew. I also worked directly with developers on implementation — making sure what shipped in code actually matched what was documented in the library, and adjusting the system when a component needed to work differently in practice than it did on paper.

Revisiting the Design System with AI

A few years later, BNY Mellon brought me back for a focused engagement: rebuilding the design system from scratch, this time specifically so it could work well with AI tools. Where the original system was built for humans reading documentation and manually matching components, this version needed structure AI could actually parse and use correctly on its own.

I set up proper tokenization — primitive tokens for raw values, and semantic tokens layered on top of them — so the system carried real meaning, not just named presets. Using Claude Design, I could generate prototypes directly and apply the platform's actual design system components to them far faster than doing it manually — since Claude could work with the token structure rather than guessing at styling from scratch.

This mattered especially given how data- and input-heavy Studio is — lots of forms, steppers, and repetitive structured screens. Once the system was set up properly, generating that kind of repetitive UI became noticeably faster than building each screen by hand.