Skip to case study
← All workDrawing less of the map for the questions banks ask every dayOverview
Product design·IBM·Data lineage in watsonx

Drawing less of the map for the questions banks ask every day

IBM's data lineage tool was built for audits: it drew every step of a bank's data pipeline, however long that took. But more and more people were opening it for quick, everyday questions and waiting hours for an answer. I chose to show almost nothing by default, kept the full map one click away, and designed the patterns so other teams could use them too.

Role
Design lead, three-person UX team
Partners
ING, State Street, Rabobank
Timeline
9 months
Research base
20+ interviews, workshops every two weeks with three client banks
Fig. 01What shipped, in three steps.IBM's lineage product still opens by saying what it's for: trust your data, investigate the pipeline, analyze what you find. Behind those three lines sit nine months, three client banks, and patterns the data integration and AI model teams went on to adapt for their own data.
IBM Watson Knowledge Catalog, Lineage tab for SAVINGS_ACCOUNTS. The starting asset sits in the centre with its business terms and 2 masked columns; three original-source CSV files sit on the left grouped as Client 360 and Customer 360 with counts like 2 of 24 assets; two reports and a model marked Final target sit on the right, each showing business terms and column counts.
Fig. 02The Summary View.Lineage opens on the data in question, with where it came from on the left and where it ends up on the right. Everything in between folds into counts like "2 of 24 assets" until someone asks.
01

A tool built only for the audit

Data lineage is how a bank proves where a number came from. Regulators expect it, and getting it wrong can cost up to $23 million in fines. For a decade, IBM Infosphere drew that map by showing every one of a pipeline's three hundred possible failure points, which took millions of database queries before anything appeared on screen.

IBM Infosphere Information Governance Catalog, Data Lineage for EFF_DURATION: an inventory panel listing 281 assets on the left and, on the right, a dense diagram of hundreds of tiny nodes joined by grey lines, too small to read
Fig. 03Built for the audit, used for everything.A small lineage by Infosphere's standards still drew 281 assets, every node too small to read, before anyone could ask a simple question.

That thoroughness made sense for an audit. It made no sense for the growing number of people who opened lineage for a quick answer about where one number came from, then waited hours and clicked more than a hundred times to get it.

02

Designing for the everyday question

ING's Chief Data Officer described the ideal as seeing the whole factory floor, "where everything is and where things are going wrong." That vision was real, and audits depend on it. But in workshops with the three client banks every two weeks, everyday users kept asking for something narrower: the first useful answer, then the option to keep going. When we tested which approach people wanted, "show me the headline, then let me drill in" beat "show me everything."

Persona and experience map for Betty, a business analyst who consumes data. The top block lists her asks, need statements, negative emotions, pain points, and requested metadata. Below, an emotional curve runs through five phases, naive use of data, guided use, development of autonomy, continuing collaboration, and mastery, with the lowest points where she cannot answer why her data is trustworthy and realizes she depends on data producers.
Fig. 04Two sides, one map.Betty, a business analyst, hits her lowest point when she can't say why her data is trustworthy. Mastery, at the far right, means moving between the business and technical sides herself.

None of the existing references solved it. A competitor, a patent filed during the project, and another IBM team each handled one part of the problem and broke on another.

Diagram labelled Competitor: one pink data lineage node joined by a dashed line to a grey hidden node with a single button, Show next node
The competitor
Fast, one step at a time, and dozens of clicks to reach a distant source.
Diagram labelled Patent: four nodes in a row, the second greyed out as a hidden node, with an arrow skipping over it from the first node to the third
The patent
Hid steps cleanly, but only ones someone had flagged by hand.
Diagram labelled Internal: two pink nodes with two grey hidden nodes between them, covered by one dark button reading Show 2 hidden nodes
The neighbor
Grouped nodes invited exploring, but the counts cost the same slow queries.

Showing less carried a real risk. An audit needs everything a piece of bad data touched, and a view that folds steps away can look like it's hiding the problem. But drawing everything was exactly what made the old tool slow and expensive. So the design kept both. The Summary View became the default for everyday questions, and one button draws the full map for an audit, with a message saying roughly how long it will take. The factory floor was still there. It just wasn't the first thing anyone had to wait for.

The call
Show where the data starts and where it ends. Draw nothing else until someone asks.
The Summary View opens on where the data came from and where it ends up, with everything between folded into counts like "2 of 24 assets." Stakeholders get the high-level story at a glance. People investigating a problem go deeper from the same screen: expand a step, filter to low quality scores or a specific owner, or narrow the view to a single column out of thousands. Built closely with the three banks, the concept beat both the other concepts and Infosphere in testing on how quickly people got to a useful answer. The first source made the difference. It was often the system of record, the one place a bank treats as the official version of its data, so seeing it right away got people to everyday answers far faster. Hours became seconds.
01IBM Watson Knowledge Catalog Lineage view for SAVINGS_ACCOUNTS, with an annotation reading: assets at either end of a lineage do not change often so it's safe to cache them, assets in the middle can change by the hour which means frequent calls to the back end for updates
02Annotated screen titled Lineage Navigation, subtitled you should be able to explore lineage like you were using Google Maps: hovering an asset reveals a directional arrow, clicking it opens a menu with Show next asset, Show assets to, and Show all
03Annotated screen of the COLLECTIONS_DW node showing 2 of 14 columns filtered into view, each with its own business terms, and a note that deeper technical, operational and governance metadata sits in a toggleable info panel
Fig. 05From a quick look to deep investigation.Land on where the data starts and ends, expand a step when needed, then filter down to the columns that matter. The diagram never gets bigger than the question.
03

Designing past the mandate

The mandate was lineage for this one project. Then two other IBM teams came asking for the same patterns: the data integration team, tracking pipeline runs, and the AI model team, tracking training data. Neither looked anything like banking transactions, but their needs weren't all that different from ours. Making the patterns work for everyone risked the ship date. Staying narrow risked several teams quietly rebuilding the same thing.

I recommended sharing them, and it wasn't a hard sell. Design leadership was glad to see the project contribute new patterns to the whole IBM design community, and the design systems team suggested changes so the patterns fit the wider system. We shipped the shared patterns on the original timeline.

04

What changed

Measured after launch, and in the years since:

Hours to seconds
Time to a useful answer
Red Dot
Award for the redesign

Six years later, IBM still ships the same patterns, and the data integration and AI model teams adapted them rather than building their own.

Fig. 06Still the front door, six years later.IBM's lineage today still opens on a Summary View of where the data starts and ends, expands a step at a time, and asks which columns are worth showing before it draws them.
05

Looking back

The call I was least sure of was how to move between levels of detail. A quick look for stakeholders and a deep investigation serve very different people, and a single dataset could carry thousands of columns, tags, and other metadata. Getting the step from one to the other right took a lot of research and many rounds of iteration.

The hardest part to manage wasn't the design, though. It was keeping seven teams aligned on decisions they had already made, and I spent hours revisiting choices people had agreed to a month earlier. Since then, every project I work on has a shared decision diary from the first week, recording what we decided, when, and why.