Password
Case study
Capital Group
An internal data marketplace that helps investment teams find, trust, and act on data scattered across the firm.
Role
Lead designer (vision), then embedded design lead (MVP)
Scope
Domain research through high-fidelity design, plus the working model for the build
Domain
Enterprise data management for a global asset manager
Context
Two-phase agency engagement, vision to build

01 — THE SITUATION
The situation I walked into
Capital Group runs on data. Investment and research decisions depend on it. But the data itself was scattered across siloed platforms, hard to find, harder to trust, and harder still to act on once you found it. People couldn't always tell whether a dataset was current, who owned it, or whether it was fit for the job in front of them.
The firm's bet was an internal data marketplace: one place to discover data products across the organization, judge whether they were trustworthy and fit for purpose, and move from finding data to actually using it.
The work came in two mandates, in sequence. First, prove the vision was worth building. Then build it.
The hard part was never a list of features. It was making an abstract, sprawling platform legible enough that people would believe in it and fund it.
02 — building understanding
Getting a team fluent in a hard domain
Before any design, the work was understanding. Enterprise data management is dense: data products and data items, lineage, stewardship, certification, quality scoring, the difference between data being recently updated and actually current. None of it designs well until you genuinely understand it.
I started with domain research and benchmarking, studying how other tools solved adjacent problems, and turned what I learned into the foundation the rest of the team worked from. I ran a workshop with stakeholders and subject-matter experts to map the space together, and the journey maps from that session surfaced where the real needs and friction sat. Getting everyone fluent in the problem was the thing that made the rest of the work possible.




03 — User research
Designing the first iteration, and validating it
I designed the prototype as a journey, not a feature tour: one path from finding data to trusting it to acting on it. I led that work from first wireframes through a high-fidelity first iteration, the version built to put in front of real users.



Then I took it into user research. I shaped the research plans, ran the sessions trading off with a teammate, and sat with seven data experts across the firm: data scientists, analysts, governance specialists, investment strategy. I synthesized what came back into a handful of themes that shaped everything after.
Taxonomy
ROLE DEPTH
DISCOVERY
TRUST
04 — Vision prototype
The final prototype that sold
I took the feedback back into the work and designed the final vision prototype. The persona sharpened to an Investment Group researcher, and the journey sharpened with it: find data, trust it, and get it into the tools where the work actually happens.
The experience opens on a personalized dashboard that surfaces the data a researcher returns to, with search and category browsing as the ways in. When a search returns too much or the right dataset isn't obvious, an AI assistant refines the query and surfaces the specific dataset, and even the specific columns, that fit the task. From there the detail view answers the trust question head on: a data quality score broken into its components, and lineage that shows where the data comes from and what it feeds downstream. The last step borrows from e-commerce. Add data to a cart, declare how it will be used, and check it out straight into Excel, Python, or wherever the analysis lives.
That arc answered the themes the sessions surfaced: readable trust signals, discovery that crosses silos instead of dead-ending, and a clean path from finding data to using it. I presented the final prototype to the client with the rationale behind each decision, not just the screens.
01 — Personalized dashboard

02 — Search: filters and detail sidebar

03 — AI-assisted discovery

04 — Detail: data quality score

05 — Detail: data lineage

06 — Checkout to Excel

Outcome
05 — Before I joined the product team
Building it inside the team
Greenlighting a build and being ready to build are two different things.
I joined the product team embedded at the client to help take the MVP from zero to one, and the team was stuck. Ownership between product and engineering was unclear, and the two functions had grown adversarial. Engineering felt decisions were being made without them. The work wasn't moving.
I came in as the representative for design. But the first problem worth solving wasn't a design problem. It was how the team worked.

06 — After I joined the product team
Fixing how the team worked
I built a collaboration model around a simple principle: every function has a voice, and no one learns about a decision after it has already been made.
In practice that was a cadence of working sessions where product and engineering worked through the details together, design in the room, so tradeoffs were visible and shared instead of handed down. Once people were actually solving problems together rather than across a wall, the adversarial dynamic had far less to feed on.
With that in place, we moved into design sprints and began working through the MVP features the vision phase had prioritized.
The most useful thing I did here wasn't a screen. It was giving a stuck team a way to make decisions together.

07 — REFLECTION
What this work proved
Across both phases, the same thing held. I can take a complex domain from research through a vision clear enough to fund, and I can embed in a product organization that isn't working and give it a way to move forward.
One half of that is craft. The other is the connective tissue a team needs to actually ship. This project asked for both.