PRODUCT DESIGN — PANTOMATH · LINEAGE 2.0
Making the
invisible
navigable.
Redesigning Lineage — Pantomath's data lineage visualization — to handle enterprise-scale data ecosystems without freezing, without losing context, and without losing the engineer.
[ROLE]
Senior Product Designer · Consultant
[TOOLS]
Figma
[YEAR]
2025
[STATUS]
Shipped to production
01
CONTEXT
What is Pantomath?
Pantomath operates as a Data Operations Center (DOC) — the data equivalent of a Security Operations Center. Their platform monitors and manages an organization's entire data analytics ecosystem in real time, with Data Reliability Engineers and AI agents working together to detect, investigate, and remediate data reliability issues before they affect business decisions.
At the core of incident investigation is Lineage — a visualization of how data flows, transforms, and depends on other assets across the entire data stack. When something breaks, Lineage is where engineers go to understand what broke, why, and what else is at risk.
02
THE PROBLEM
The graph was collapsing under its own weight.
Enterprise data ecosystems are not small. Pantomath's clients operate with hundreds — sometimes thousands — of interconnected assets, pipelines, and jobs. The existing Lineage visualization attempted to render all of it at once.
The result: the interface froze. Engineers waiting for a graph to load during an active incident is not a UX inconvenience — it's a direct hit to Mean Time To Resolution (MTTR). And when it did load, the density of nodes made it nearly impossible to extract meaning without significant manual navigation.
"When something breaks, engineers need answers in seconds. A frozen screen is not an option."
∞
Effective load time for large pipelines in the previous version — the render never completed.
0
Filtering or progressive disclosure mechanisms in v1 — everything rendered at once.
2
Ways to exit the situation — close the tab or wait indefinitely.
03
USERS
Who uses Lineage, and why it matters that they're different.
Lineage serves three distinct roles inside a Data Operations Center, each with a different relationship to the data, a different level of urgency, and a different definition of "useful." Designing for only one of them would have solved part of the problem.
Primary User
Data Reliability Engineer
Frustration:
The visualization freezes or loads too slowly to be useful during an active incident — forcing manual workarounds under pressure.
Goal:
Trace upstream to the root cause and understand downstream impact as fast as possible.
Secondary User
Data Engineer
Frustration:
Uses Lineage infrequently — each time, re-orienting in a dense graph takes more time than the actual task.
Goal:
Locate a specific asset or pipeline and understand its direct dependencies before making structural changes.
Tertiary User
Data Operations Manager
Frustration:
The interface is built for engineers. Getting a high-level picture of incident scope requires navigating a tool designed for someone else.
Goal:
Quickly confirm the scope and impact of an active incident without needing technical assistance.
04
PROCESS
From flow to fidelity in two weeks.
The design was built on top of Unify — Pantomath's design system — which made it possible to move from concept to production-ready screens without rebuilding foundations. The process was iterative and structured, with each phase informing the next.
- User Flow
Before touching any visual, the full experience was mapped as a user flow. Three entry points (Pipelines Page, Lineage Explorer, Catalog/Incident Page), a central decision branch — does the user want to explore the lineage? — and two main paths: graph navigation with filters and trace, and bulk actions for promote/export. Each END state was explicitly defined.
Watch User Flow
- Paper Wireframes
Low-fidelity exploration on paper to test layout logic before committing to any digital structure. Multiple iterations of the graph view, the sidebar navigation, and the table view were sketched to validate the information architecture before any pixel work.
Paper Wireframes
- Wireflow
Digital wireframes connected directly to the user flow logic — a wireflow that made the interaction model testable before high fidelity. This was the artifact used to align with the PM and engineering team on scope and feasibility before investing in polish.
Watch Wireflow
- High Fidelity
Built directly on Unify — Pantomath's design system. Using an established component library and design tokens meant zero time rebuilding foundations. The focus was entirely on solving the interaction problems, not on visual production. This is what made two weeks possible.
Watch Mockup
05
SOLUTION
Progressive disclosure. Two views. One coherent system.
The core design decision was to stop trying to show everything at once. Lineage 2.0 introduces a layered approach to visualization — users control depth, direction, and detail. The interface renders what's relevant, not what's possible.
FEATURE 01
Depth & Direction Controls
Users set upstream and downstream depth independently, along with global depth. The graph renders only what was asked for — preventing the render overload that made v1 unusable on large pipelines.
FEATURE 02
Smart Filtering
Filter by Platform, Status, Asset Type, and Tags before the graph renders. Users arrive at a focused view of their specific problem, not a maze they have to navigate out of.
FEATURE 03
Trace Path
One-click trace to highlight the shortest path between two endpoints — upstream to root cause or downstream to impact radius. The critical action for incident investigation, surfaced directly in the graph.
FEATURE 04
Lineage Explorer Table View
An alternative to the graph — a structured table with the same data, sortable and filterable. For users who think in rows, not nodes. The same information, a completely different cognitive model.
06
OUTCOME
From frozen screen
to production in
two weeks.
The redesign went from first user flow to client-ready validation in two weeks — a timeline made possible by a structured design process and a design system that eliminated rework at every stage.
The render performance issue was resolved at the design level — progressive disclosure and depth controls mean the interface never attempts to load more than the user explicitly requests.
Two distinct views — Graph and Table — serve different cognitive models without fragmenting the product. The same underlying data, two valid interfaces.
The designs were validated with the PM and the Customer Experience team, and received a green light to move directly into engineering production.
Lineage 2.0 shipped. It now runs live in Pantomath's platform, used by Data Reliability Engineers navigating real incidents across enterprise data ecosystems.
07
REFLECTION
What this project actually taught me.
Working in a highly technical domain without direct access to user research data meant leaning hard on domain knowledge, PM collaboration, and the existing product to understand what users actually needed. The user personas weren't built from interviews — they were built from the product's own documentation, the incident management logic baked into the platform, and close collaboration with the team that spoke to clients daily.
The two-week timeline wasn't a constraint I pushed through — it was the result of having Unify already in place. When the design system exists and works, design velocity is a byproduct. This project is proof of why investing in systems before features is always the right call.
PRODUCT DESIGN — PANTOMATH · LINEAGE 2.0
Making the
invisible
navigable.
Redesigning Lineage — Pantomath's data lineage visualization — to handle enterprise-scale data ecosystems without freezing, without losing context, and without losing the engineer.
[ROLE]
Senior Product Designer · Consultant
[TOOLS]
Figma
[YEAR]
2025
[STATUS]
Shipped to production
01
CONTEXT
What is Pantomath?
Pantomath operates as a Data Operations Center (DOC) — the data equivalent of a Security Operations Center. Their platform monitors and manages an organization's entire data analytics ecosystem in real time, with Data Reliability Engineers and AI agents working together to detect, investigate, and remediate data reliability issues before they affect business decisions.
At the core of incident investigation is Lineage — a visualization of how data flows, transforms, and depends on other assets across the entire data stack. When something breaks, Lineage is where engineers go to understand what broke, why, and what else is at risk.
02
THE PROBLEM
The graph was collapsing under its own weight.
Enterprise data ecosystems are not small. Pantomath's clients operate with hundreds — sometimes thousands — of interconnected assets, pipelines, and jobs. The existing Lineage visualization attempted to render all of it at once.
The result: the interface froze. Engineers waiting for a graph to load during an active incident is not a UX inconvenience — it's a direct hit to Mean Time To Resolution (MTTR). And when it did load, the density of nodes made it nearly impossible to extract meaning without significant manual navigation.
"When something breaks, engineers need answers in seconds. A frozen screen is not an option."
∞
Effective load time for large pipelines in the previous version — the render never completed.
0
Filtering or progressive disclosure mechanisms in v1 — everything rendered at once.
2
Ways to exit the situation — close the tab or wait indefinitely.
03
USERS
Who uses Lineage, and why it matters that they're different.
Lineage serves three distinct roles inside a Data Operations Center, each with a different relationship to the data, a different level of urgency, and a different definition of "useful." Designing for only one of them would have solved part of the problem.
Primary User
Data Reliability Engineer
Frustration:
The visualization freezes or loads too slowly to be useful during an active incident — forcing manual workarounds under pressure.
Goal:
Trace upstream to the root cause and understand downstream impact as fast as possible.
Secondary User
Data Engineer
Frustration:
Uses Lineage infrequently — each time, re-orienting in a dense graph takes more time than the actual task.
Goal:
Locate a specific asset or pipeline and understand its direct dependencies before making structural changes.
Tertiary User
Data Operations Manager
Frustration:
The interface is built for engineers. Getting a high-level picture of incident scope requires navigating a tool designed for someone else.
Goal:
Quickly confirm the scope and impact of an active incident without needing technical assistance.
04
PROCESS
From flow to fidelity in two weeks.
The design was built on top of Unify — Pantomath's design system — which made it possible to move from concept to production-ready screens without rebuilding foundations. The process was iterative and structured, with each phase informing the next.
- User Flow
Before touching any visual, the full experience was mapped as a user flow. Three entry points (Pipelines Page, Lineage Explorer, Catalog/Incident Page), a central decision branch — does the user want to explore the lineage? — and two main paths: graph navigation with filters and trace, and bulk actions for promote/export. Each END state was explicitly defined.
Watch User Flow
- Paper Wireframes
Low-fidelity exploration on paper to test layout logic before committing to any digital structure. Multiple iterations of the graph view, the sidebar navigation, and the table view were sketched to validate the information architecture before any pixel work.
Watch Paper Wireframes
- Wireflow
Digital wireframes connected directly to the user flow logic — a wireflow that made the interaction model testable before high fidelity. This was the artifact used to align with the PM and engineering team on scope and feasibility before investing in polish.
Watch Wireflow
- High Fidelity
Built directly on Unify — Pantomath's design system. Using an established component library and design tokens meant zero time rebuilding foundations. The focus was entirely on solving the interaction problems, not on visual production. This is what made two weeks possible.
Watch Mockup
05
SOLUTION
Progressive disclosure. Two views. One coherent system.
The core design decision was to stop trying to show everything at once. Lineage 2.0 introduces a layered approach to visualization — users control depth, direction, and detail. The interface renders what's relevant, not what's possible.
FEATURE 01
Depth & Direction Controls
Users set upstream and downstream depth independently, along with global depth. The graph renders only what was asked for — preventing the render overload that made v1 unusable on large pipelines.
FEATURE 02
Smart Filtering
Filter by Platform, Status, Asset Type, and Tags before the graph renders. Users arrive at a focused view of their specific problem, not a maze they have to navigate out of.
FEATURE 03
Trace Path
One-click trace to highlight the shortest path between two endpoints — upstream to root cause or downstream to impact radius. The critical action for incident investigation, surfaced directly in the graph.
FEATURE 04
Lineage Explorer Table View
An alternative to the graph — a structured table with the same data, sortable and filterable. For users who think in rows, not nodes. The same information, a completely different cognitive model.
06
OUTCOME
From frozen screen
to production in
two weeks.
The redesign went from first user flow to client-ready validation in two weeks — a timeline made possible by a structured design process and a design system that eliminated rework at every stage.
The render performance issue was resolved at the design level — progressive disclosure and depth controls mean the interface never attempts to load more than the user explicitly requests.
Two distinct views — Graph and Table — serve different cognitive models without fragmenting the product. The same underlying data, two valid interfaces.
The designs were validated with the PM and the Customer Experience team, and received a green light to move directly into engineering production.
Lineage 2.0 shipped. It now runs live in Pantomath's platform, used by Data Reliability Engineers navigating real incidents across enterprise data ecosystems.
07
REFLECTION
What this project actually taught me.
Working in a highly technical domain without direct access to user research data meant leaning hard on domain knowledge, PM collaboration, and the existing product to understand what users actually needed. The user personas weren't built from interviews — they were built from the product's own documentation, the incident management logic baked into the platform, and close collaboration with the team that spoke to clients daily.
The two-week timeline wasn't a constraint I pushed through — it was the result of having Unify already in place. When the design system exists and works, design velocity is a byproduct. This project is proof of why investing in systems before features is always the right call.
PRODUCT DESIGN — PANTOMATH · LINEAGE 2.0
Making the
invisible
navigable.
Redesigning Lineage — Pantomath's data lineage visualization — to handle enterprise-scale data ecosystems without freezing, without losing context, and without losing the engineer.
[ROLE]
Senior Product Designer · Consultant
[TOOLS]
Figma
[YEAR]
2025
[STATUS]
Shipped to production
01
CONTEXT
What is Pantomath?
Pantomath operates as a Data Operations Center (DOC) — the data equivalent of a Security Operations Center. Their platform monitors and manages an organization's entire data analytics ecosystem in real time, with Data Reliability Engineers and AI agents working together to detect, investigate, and remediate data reliability issues before they affect business decisions.
At the core of incident investigation is Lineage — a visualization of how data flows, transforms, and depends on other assets across the entire data stack. When something breaks, Lineage is where engineers go to understand what broke, why, and what else is at risk.
02
THE PROBLEM
The graph was collapsing under its own weight.
Enterprise data ecosystems are not small. Pantomath's clients operate with hundreds — sometimes thousands — of interconnected assets, pipelines, and jobs. The existing Lineage visualization attempted to render all of it at once.
The result: the interface froze. Engineers waiting for a graph to load during an active incident is not a UX inconvenience — it's a direct hit to Mean Time To Resolution (MTTR). And when it did load, the density of nodes made it nearly impossible to extract meaning without significant manual navigation.
"When something breaks, engineers need answers in seconds. A frozen screen is not an option."
∞
Effective load time for large pipelines in the previous version — the render never completed.
0
Filtering or progressive disclosure mechanisms in v1 — everything rendered at once.
2
Ways to exit the situation — close the tab or wait indefinitely.
03
USERS
Who uses Lineage, and why it matters that they're different.
Lineage serves three distinct roles inside a Data Operations Center, each with a different relationship to the data, a different level of urgency, and a different definition of "useful." Designing for only one of them would have solved part of the problem.
Primary User
Data Reliability Engineer
Frustration:
The visualization freezes or loads too slowly to be useful during an active incident — forcing manual workarounds under pressure.
Goal:
Trace upstream to the root cause and understand downstream impact as fast as possible.
Secondary User
Data Engineer
Frustration:
Uses Lineage infrequently — each time, re-orienting in a dense graph takes more time than the actual task.
Goal:
Locate a specific asset or pipeline and understand its direct dependencies before making structural changes.
Tertiary User
Data Operations Manager
Frustration:
The interface is built for engineers. Getting a high-level picture of incident scope requires navigating a tool designed for someone else.
Goal:
Quickly confirm the scope and impact of an active incident without needing technical assistance.
04
PROCESS
From flow to fidelity in two weeks.
The design was built on top of Unify — Pantomath's design system — which made it possible to move from concept to production-ready screens without rebuilding foundations. The process was iterative and structured, with each phase informing the next.
- User Flow
Before touching any visual, the full experience was mapped as a user flow. Three entry points (Pipelines Page, Lineage Explorer, Catalog/Incident Page), a central decision branch — does the user want to explore the lineage? — and two main paths: graph navigation with filters and trace, and bulk actions for promote/export. Each END state was explicitly defined.
Watch User Flow
- Paper Wireframes
Low-fidelity exploration on paper to test layout logic before committing to any digital structure. Multiple iterations of the graph view, the sidebar navigation, and the table view were sketched to validate the information architecture before any pixel work.
Watch Paper Wireframes
- Wireflow
Digital wireframes connected directly to the user flow logic — a wireflow that made the interaction model testable before high fidelity. This was the artifact used to align with the PM and engineering team on scope and feasibility before investing in polish.
Watch Wireflow
- High Fidelity
Built directly on Unify — Pantomath's design system. Using an established component library and design tokens meant zero time rebuilding foundations. The focus was entirely on solving the interaction problems, not on visual production. This is what made two weeks possible.
Watch Mockup
05
SOLUTION
Progressive disclosure. Two views. One coherent system.
The core design decision was to stop trying to show everything at once. Lineage 2.0 introduces a layered approach to visualization — users control depth, direction, and detail. The interface renders what's relevant, not what's possible.
FEATURE 01
Depth & Direction Controls
Users set upstream and downstream depth independently, along with global depth. The graph renders only what was asked for — preventing the render overload that made v1 unusable on large pipelines.
FEATURE 02
Smart Filtering
Filter by Platform, Status, Asset Type, and Tags before the graph renders. Users arrive at a focused view of their specific problem, not a maze they have to navigate out of.
FEATURE 03
Trace Path
One-click trace to highlight the shortest path between two endpoints — upstream to root cause or downstream to impact radius. The critical action for incident investigation, surfaced directly in the graph.
FEATURE 04
Lineage Explorer Table View
An alternative to the graph — a structured table with the same data, sortable and filterable. For users who think in rows, not nodes. The same information, a completely different cognitive model.
06
OUTCOME
From frozen screen
to production in
two weeks.
The redesign went from first user flow to client-ready validation in two weeks — a timeline made possible by a structured design process and a design system that eliminated rework at every stage.
The render performance issue was resolved at the design level — progressive disclosure and depth controls mean the interface never attempts to load more than the user explicitly requests.
Two distinct views — Graph and Table — serve different cognitive models without fragmenting the product. The same underlying data, two valid interfaces.
The designs were validated with the PM and the Customer Experience team, and received a green light to move directly into engineering production.
Lineage 2.0 shipped. It now runs live in Pantomath's platform, used by Data Reliability Engineers navigating real incidents across enterprise data ecosystems.
07
REFLECTION
What this project actually taught me.
Working in a highly technical domain without direct access to user research data meant leaning hard on domain knowledge, PM collaboration, and the existing product to understand what users actually needed. The user personas weren't built from interviews — they were built from the product's own documentation, the incident management logic baked into the platform, and close collaboration with the team that spoke to clients daily.
The two-week timeline wasn't a constraint I pushed through — it was the result of having Unify already in place. When the design system exists and works, design velocity is a byproduct. This project is proof of why investing in systems before features is always the right call.
PRODUCT DESIGN — PANTOMATH · LINEAGE 2.0
Making the
invisible
navigable.
Redesigning Lineage — Pantomath's data lineage visualization — to handle enterprise-scale data ecosystems without freezing, without losing context, and without losing the engineer.
[ROLE]
Senior Product Designer · Consultant
[TOOLS]
Figma
[YEAR]
2025
[STATUS]
Shipped to production
01
CONTEXT
What is Pantomath?
Pantomath operates as a Data Operations Center (DOC) — the data equivalent of a Security Operations Center. Their platform monitors and manages an organization's entire data analytics ecosystem in real time, with Data Reliability Engineers and AI agents working together to detect, investigate, and remediate data reliability issues before they affect business decisions.
At the core of incident investigation is Lineage — a visualization of how data flows, transforms, and depends on other assets across the entire data stack. When something breaks, Lineage is where engineers go to understand what broke, why, and what else is at risk.
02
THE PROBLEM
The graph was collapsing under its own weight.
Enterprise data ecosystems are not small. Pantomath's clients operate with hundreds — sometimes thousands — of interconnected assets, pipelines, and jobs. The existing Lineage visualization attempted to render all of it at once.
The result: the interface froze. Engineers waiting for a graph to load during an active incident is not a UX inconvenience — it's a direct hit to Mean Time To Resolution (MTTR). And when it did load, the density of nodes made it nearly impossible to extract meaning without significant manual navigation.
"When something breaks, engineers need answers in seconds. A frozen screen is not an option."
∞
Effective load time for large pipelines in the previous version — the render never completed.
0
Filtering or progressive disclosure mechanisms in v1 — everything rendered at once.
2
Ways to exit the situation — close the tab or wait indefinitely.
03
USERS
Who uses Lineage, and why it matters that they're different.
Lineage serves three distinct roles inside a Data Operations Center, each with a different relationship to the data, a different level of urgency, and a different definition of "useful." Designing for only one of them would have solved part of the problem.
Primary User
Data Reliability Engineer
Frustration:
The visualization freezes or loads too slowly to be useful during an active incident — forcing manual workarounds under pressure.
Goal:
Trace upstream to the root cause and understand downstream impact as fast as possible.
Secondary User
Data Engineer
Frustration:
Uses Lineage infrequently — each time, re-orienting in a dense graph takes more time than the actual task.
Goal:
Locate a specific asset or pipeline and understand its direct dependencies before making structural changes.
Tertiary User
Data Operations Manager
Frustration:
The interface is built for engineers. Getting a high-level picture of incident scope requires navigating a tool designed for someone else.
Goal:
Quickly confirm the scope and impact of an active incident without needing technical assistance.
04
PROCESS
From flow to fidelity in two weeks.
The design was built on top of Unify — Pantomath's design system — which made it possible to move from concept to production-ready screens without rebuilding foundations. The process was iterative and structured, with each phase informing the next.
- User Flow
Before touching any visual, the full experience was mapped as a user flow. Three entry points (Pipelines Page, Lineage Explorer, Catalog/Incident Page), a central decision branch — does the user want to explore the lineage? — and two main paths: graph navigation with filters and trace, and bulk actions for promote/export. Each END state was explicitly defined.
Watch User Flow
- Paper Wireframes
Low-fidelity exploration on paper to test layout logic before committing to any digital structure. Multiple iterations of the graph view, the sidebar navigation, and the table view were sketched to validate the information architecture before any pixel work.
Watch Paper Wireframes
- Wireflow
Digital wireframes connected directly to the user flow logic — a wireflow that made the interaction model testable before high fidelity. This was the artifact used to align with the PM and engineering team on scope and feasibility before investing in polish.
Watch Wireflow
- High Fidelity
Built directly on Unify — Pantomath's design system. Using an established component library and design tokens meant zero time rebuilding foundations. The focus was entirely on solving the interaction problems, not on visual production. This is what made two weeks possible.
Watch Mockup
05
SOLUTION
Progressive disclosure. Two views. One coherent system.
The core design decision was to stop trying to show everything at once. Lineage 2.0 introduces a layered approach to visualization — users control depth, direction, and detail. The interface renders what's relevant, not what's possible.
FEATURE 01
Depth & Direction Controls
Users set upstream and downstream depth independently, along with global depth. The graph renders only what was asked for — preventing the render overload that made v1 unusable on large pipelines.
FEATURE 02
Smart Filtering
Filter by Platform, Status, Asset Type, and Tags before the graph renders. Users arrive at a focused view of their specific problem, not a maze they have to navigate out of.
FEATURE 03
Trace Path
One-click trace to highlight the shortest path between two endpoints — upstream to root cause or downstream to impact radius. The critical action for incident investigation, surfaced directly in the graph.
FEATURE 04
Lineage Explorer Table View
An alternative to the graph — a structured table with the same data, sortable and filterable. For users who think in rows, not nodes. The same information, a completely different cognitive model.
06
OUTCOME
From frozen screen
to production in
two weeks.
The redesign went from first user flow to client-ready validation in two weeks — a timeline made possible by a structured design process and a design system that eliminated rework at every stage.
The render performance issue was resolved at the design level — progressive disclosure and depth controls mean the interface never attempts to load more than the user explicitly requests.
Two distinct views — Graph and Table — serve different cognitive models without fragmenting the product. The same underlying data, two valid interfaces.
The designs were validated with the PM and the Customer Experience team, and received a green light to move directly into engineering production.
Lineage 2.0 shipped. It now runs live in Pantomath's platform, used by Data Reliability Engineers navigating real incidents across enterprise data ecosystems.
07
REFLECTION
What this project actually taught me.
Working in a highly technical domain without direct access to user research data meant leaning hard on domain knowledge, PM collaboration, and the existing product to understand what users actually needed. The user personas weren't built from interviews — they were built from the product's own documentation, the incident management logic baked into the platform, and close collaboration with the team that spoke to clients daily.
The two-week timeline wasn't a constraint I pushed through — it was the result of having Unify already in place. When the design system exists and works, design velocity is a byproduct. This project is proof of why investing in systems before features is always the right call.
PRODUCT DESIGN — PANTOMATH · LINEAGE 2.0
Making the
invisible
navigable.
Redesigning Lineage — Pantomath's data lineage visualization — to handle enterprise-scale data ecosystems without freezing, without losing context, and without losing the engineer.
[ROLE]
Senior Product Designer · Consultant
[TOOLS]
Figma
[YEAR]
2025
[STATUS]
Shipped to production
01
CONTEXT
What is Pantomath?
Pantomath operates as a Data Operations Center (DOC) — the data equivalent of a Security Operations Center. Their platform monitors and manages an organization's entire data analytics ecosystem in real time, with Data Reliability Engineers and AI agents working together to detect, investigate, and remediate data reliability issues before they affect business decisions.
At the core of incident investigation is Lineage — a visualization of how data flows, transforms, and depends on other assets across the entire data stack. When something breaks, Lineage is where engineers go to understand what broke, why, and what else is at risk.
02
THE PROBLEM
The graph was collapsing under its own weight.
Enterprise data ecosystems are not small. Pantomath's clients operate with hundreds — sometimes thousands — of interconnected assets, pipelines, and jobs. The existing Lineage visualization attempted to render all of it at once.
The result: the interface froze. Engineers waiting for a graph to load during an active incident is not a UX inconvenience — it's a direct hit to Mean Time To Resolution (MTTR). And when it did load, the density of nodes made it nearly impossible to extract meaning without significant manual navigation.
"When something breaks, engineers need answers in seconds. A frozen screen is not an option."
∞
Effective load time for large pipelines in the previous version — the render never completed.
0
Filtering or progressive disclosure mechanisms in v1 — everything rendered at once.
2
Ways to exit the situation — close the tab or wait indefinitely.
03
USERS
Who uses Lineage, and why it matters that they're different.
Lineage serves three distinct roles inside a Data Operations Center, each with a different relationship to the data, a different level of urgency, and a different definition of "useful." Designing for only one of them would have solved part of the problem.
Primary User
Data Reliability Engineer
Frustration:
The visualization freezes or loads too slowly to be useful during an active incident — forcing manual workarounds under pressure.
Goal:
Trace upstream to the root cause and understand downstream impact as fast as possible.
Secondary User
Data Engineer
Frustration:
Uses Lineage infrequently — each time, re-orienting in a dense graph takes more time than the actual task.
Goal:
Locate a specific asset or pipeline and understand its direct dependencies before making structural changes.
Tertiary User
Data Operations Manager
Frustration:
The interface is built for engineers. Getting a high-level picture of incident scope requires navigating a tool designed for someone else.
Goal:
Quickly confirm the scope and impact of an active incident without needing technical assistance.
04
PROCESS
From flow to fidelity in two weeks.
The design was built on top of Unify — Pantomath's design system — which made it possible to move from concept to production-ready screens without rebuilding foundations. The process was iterative and structured, with each phase informing the next.
- User Flow
Before touching any visual, the full experience was mapped as a user flow. Three entry points (Pipelines Page, Lineage Explorer, Catalog/Incident Page), a central decision branch — does the user want to explore the lineage? — and two main paths: graph navigation with filters and trace, and bulk actions for promote/export. Each END state was explicitly defined.
Watch User Flow
- Paper Wireframes
Low-fidelity exploration on paper to test layout logic before committing to any digital structure. Multiple iterations of the graph view, the sidebar navigation, and the table view were sketched to validate the information architecture before any pixel work.
Watch Paper Wireframes
- Wireflow
Digital wireframes connected directly to the user flow logic — a wireflow that made the interaction model testable before high fidelity. This was the artifact used to align with the PM and engineering team on scope and feasibility before investing in polish.
Watch Wireflow
- High Fidelity
Built directly on Unify — Pantomath's design system. Using an established component library and design tokens meant zero time rebuilding foundations. The focus was entirely on solving the interaction problems, not on visual production. This is what made two weeks possible.
Watch Mockup
05
SOLUTION
Progressive disclosure. Two views. One coherent system.
The core design decision was to stop trying to show everything at once. Lineage 2.0 introduces a layered approach to visualization — users control depth, direction, and detail. The interface renders what's relevant, not what's possible.
FEATURE 01
Depth & Direction Controls
Users set upstream and downstream depth independently, along with global depth. The graph renders only what was asked for — preventing the render overload that made v1 unusable on large pipelines.
FEATURE 02
Smart Filtering
Filter by Platform, Status, Asset Type, and Tags before the graph renders. Users arrive at a focused view of their specific problem, not a maze they have to navigate out of.
FEATURE 03
Trace Path
One-click trace to highlight the shortest path between two endpoints — upstream to root cause or downstream to impact radius. The critical action for incident investigation, surfaced directly in the graph.
FEATURE 04
Lineage Explorer Table View
An alternative to the graph — a structured table with the same data, sortable and filterable. For users who think in rows, not nodes. The same information, a completely different cognitive model.
06
OUTCOME
From frozen screen
to production in
two weeks.
The redesign went from first user flow to client-ready validation in two weeks — a timeline made possible by a structured design process and a design system that eliminated rework at every stage.
The render performance issue was resolved at the design level — progressive disclosure and depth controls mean the interface never attempts to load more than the user explicitly requests.
Two distinct views — Graph and Table — serve different cognitive models without fragmenting the product. The same underlying data, two valid interfaces.
The designs were validated with the PM and the Customer Experience team, and received a green light to move directly into engineering production.
Lineage 2.0 shipped. It now runs live in Pantomath's platform, used by Data Reliability Engineers navigating real incidents across enterprise data ecosystems.
07
REFLECTION
What this project actually taught me.
Working in a highly technical domain without direct access to user research data meant leaning hard on domain knowledge, PM collaboration, and the existing product to understand what users actually needed. The user personas weren't built from interviews — they were built from the product's own documentation, the incident management logic baked into the platform, and close collaboration with the team that spoke to clients daily.
The two-week timeline wasn't a constraint I pushed through — it was the result of having Unify already in place. When the design system exists and works, design velocity is a byproduct. This project is proof of why investing in systems before features is always the right call.
PRODUCT DESIGN — PANTOMATH · LINEAGE 2.0
Making the
invisible
navigable.
Redesigning Lineage — Pantomath's data lineage visualization — to handle enterprise-scale data ecosystems without freezing, without losing context, and without losing the engineer.
[ROLE]
Senior Product Designer · Consultant
[TOOLS]
Figma
[YEAR]
2025
[STATUS]
Shipped to production
01
CONTEXT
What is Pantomath?
Pantomath operates as a Data Operations Center (DOC) — the data equivalent of a Security Operations Center. Their platform monitors and manages an organization's entire data analytics ecosystem in real time, with Data Reliability Engineers and AI agents working together to detect, investigate, and remediate data reliability issues before they affect business decisions.
At the core of incident investigation is Lineage — a visualization of how data flows, transforms, and depends on other assets across the entire data stack. When something breaks, Lineage is where engineers go to understand what broke, why, and what else is at risk.
02
THE PROBLEM
The graph was collapsing under its own weight.
Enterprise data ecosystems are not small. Pantomath's clients operate with hundreds — sometimes thousands — of interconnected assets, pipelines, and jobs. The existing Lineage visualization attempted to render all of it at once.
The result: the interface froze. Engineers waiting for a graph to load during an active incident is not a UX inconvenience — it's a direct hit to Mean Time To Resolution (MTTR). And when it did load, the density of nodes made it nearly impossible to extract meaning without significant manual navigation.
"When something breaks, engineers need answers in seconds. A frozen screen is not an option."
∞
Effective load time for large pipelines in the previous version — the render never completed.
0
Filtering or progressive disclosure mechanisms in v1 — everything rendered at once.
2
Ways to exit the situation — close the tab or wait indefinitely.
03
USERS
Who uses Lineage, and why it matters that they're different.
Lineage serves three distinct roles inside a Data Operations Center, each with a different relationship to the data, a different level of urgency, and a different definition of "useful." Designing for only one of them would have solved part of the problem.
Primary User
Data Reliability Engineer
Frustration:
The visualization freezes or loads too slowly to be useful during an active incident — forcing manual workarounds under pressure.
Goal:
Trace upstream to the root cause and understand downstream impact as fast as possible.
Secondary User
Data Engineer
Frustration:
Uses Lineage infrequently — each time, re-orienting in a dense graph takes more time than the actual task.
Goal:
Locate a specific asset or pipeline and understand its direct dependencies before making structural changes.
Tertiary User
Data Operations Manager
Frustration:
The interface is built for engineers. Getting a high-level picture of incident scope requires navigating a tool designed for someone else.
Goal:
Quickly confirm the scope and impact of an active incident without needing technical assistance.
04
PROCESS
From flow to fidelity in two weeks.
The design was built on top of Unify — Pantomath's design system — which made it possible to move from concept to production-ready screens without rebuilding foundations. The process was iterative and structured, with each phase informing the next.
- User Flow
Before touching any visual, the full experience was mapped as a user flow. Three entry points (Pipelines Page, Lineage Explorer, Catalog/Incident Page), a central decision branch — does the user want to explore the lineage? — and two main paths: graph navigation with filters and trace, and bulk actions for promote/export. Each END state was explicitly defined.
Watch User Flow
- Paper Wireframes
Low-fidelity exploration on paper to test layout logic before committing to any digital structure. Multiple iterations of the graph view, the sidebar navigation, and the table view were sketched to validate the information architecture before any pixel work.
Watch Paper Wireframes
- Wireflow
Digital wireframes connected directly to the user flow logic — a wireflow that made the interaction model testable before high fidelity. This was the artifact used to align with the PM and engineering team on scope and feasibility before investing in polish.
Watch Wireflow
- High Fidelity
Built directly on Unify — Pantomath's design system. Using an established component library and design tokens meant zero time rebuilding foundations. The focus was entirely on solving the interaction problems, not on visual production. This is what made two weeks possible.
Watch Mockup
05
SOLUTION
Progressive disclosure. Two views. One coherent system.
The core design decision was to stop trying to show everything at once. Lineage 2.0 introduces a layered approach to visualization — users control depth, direction, and detail. The interface renders what's relevant, not what's possible.
FEATURE 01
Depth & Direction Controls
Users set upstream and downstream depth independently, along with global depth. The graph renders only what was asked for — preventing the render overload that made v1 unusable on large pipelines.
FEATURE 02
Smart Filtering
Filter by Platform, Status, Asset Type, and Tags before the graph renders. Users arrive at a focused view of their specific problem, not a maze they have to navigate out of.
FEATURE 03
Trace Path
One-click trace to highlight the shortest path between two endpoints — upstream to root cause or downstream to impact radius. The critical action for incident investigation, surfaced directly in the graph.
FEATURE 04
Lineage Explorer Table View
An alternative to the graph — a structured table with the same data, sortable and filterable. For users who think in rows, not nodes. The same information, a completely different cognitive model.
06
OUTCOME
From frozen screen
to production in
two weeks.
The redesign went from first user flow to client-ready validation in two weeks — a timeline made possible by a structured design process and a design system that eliminated rework at every stage.
The render performance issue was resolved at the design level — progressive disclosure and depth controls mean the interface never attempts to load more than the user explicitly requests.
Two distinct views — Graph and Table — serve different cognitive models without fragmenting the product. The same underlying data, two valid interfaces.
The designs were validated with the PM and the Customer Experience team, and received a green light to move directly into engineering production.
Lineage 2.0 shipped. It now runs live in Pantomath's platform, used by Data Reliability Engineers navigating real incidents across enterprise data ecosystems.
07
REFLECTION
What this project actually taught me.
Working in a highly technical domain without direct access to user research data meant leaning hard on domain knowledge, PM collaboration, and the existing product to understand what users actually needed. The user personas weren't built from interviews — they were built from the product's own documentation, the incident management logic baked into the platform, and close collaboration with the team that spoke to clients daily.
The two-week timeline wasn't a constraint I pushed through — it was the result of having Unify already in place. When the design system exists and works, design velocity is a byproduct. This project is proof of why investing in systems before features is always the right call.