Rupesh N. Chavan Enterprise SaaS / Data Platform 2023-2024

Making Data
Infrastructure Feel
Like Software

Redesigning OpenMetadata's platform UX and marketing website. Making enterprise-grade data discovery, lineage, and governance feel as intuitive as a consumer product.

View Live App Marketing Website
OpenMetadata · interface
RoleLead Product Designer
Timeline2023-2024
PlatformWeb App + Marketing Site
CategoryEnterprise Open-Source
12.8k
Tables Catalogued
▲ 8%
98%
Lineage Coverage
Across 12 connectors
Data Discovery Data Lineage Data Governance 500+ Integrations ISO 27001 Compliant 50K+ Active Users Semantic Search Role-Based Access Enterprise Open Source duplicate for smooth loop Data Discovery Data Lineage Data Governance 500+ Integrations ISO 27001 Compliant 50K+ Active Users Semantic Search Role-Based Access Enterprise Open Source

OpenMetadata is one of the world's most complete open-source data catalog and metadata management platforms. Despite its powerful backend, the user experience needed a complete rethink. One that would serve both the data engineer writing SQL at 2am and the CDO presenting data governance posture to a board.

My scope covered the full product experience: the core application UX, the information architecture for 200+ entity types, and the marketing website that had to translate deeply technical capabilities into business value for enterprise buyers.

Sole designer responsible for both the product and the marketing site. Worked directly with the founding engineering team, research from enterprise design partners, and conducted usability testing across data engineer, analyst, and data governance personas.

50K+
Active Users
500+
Native Integrations
3x
Search Speed Increase
ISO 27001
Security Compliant
The Challenge
My Contribution
Product Strategy Information Architecture UI System Design Data Visualization Navigation Design Marketing Website Component Library User Research
The problem
Enterprise data discovery, lineage and governance are genuinely complex, and most tools pass that complexity straight to the user.
The approach
Make the hard thing feel simple without hiding it. Clear hierarchy, progressive depth, and lineage rendered as something readable.
The outcome
A platform UX and marketing site where discovery and governance feel approachable at first contact.
1
Discovery surface
1
Lineage view
1
Governance model
2
Surfaces designed
Research & Problem

Data teams were
flying blind

Enterprise data teams had no unified view of their data landscape. Metadata was scattered across warehouses, BI tools, and pipelines. Data engineers spent 40% of their working time just finding and understanding data, not analyzing it. The real problem was invisible infrastructure.

01 · Discovery
The Data Discovery Problem
Data engineers spent an average of 2.5 hours per day searching for the right dataset. Discovery was tribal knowledge, not systematic. The "right" dataset lived in someone's head, not in any tool. New hires took months to reach full productivity.
02 · Trust
Trust and Lineage
Without data lineage visualization, teams couldn't trust data freshness or understand upstream/downstream dependencies. A single schema change in a source database would silently break 12 dashboards. There was no way to see the blast radius before making changes.
03 · Governance
Governance Complexity
Data governance tools were either too technical (CLI-only, no visualisation) or too simplified (no depth for power users). Enterprise teams needed both: the power of a developer tool and the accessibility of a business application, in the same interface.
05 · User Stories

What Users Need

As a... I want to... So that... Priority
Data Engineer Search for datasets by name, tag, or description instantly I stop spending hours asking colleagues which table to use High
Data Scientist See data lineage and ownership on every dataset I can trust the data before investing modelling time High
Governance Lead Define and enforce data policies across all assets Compliance is automated rather than manually audited High
Data Consumer See freshness indicators and quality scores inline I know whether the data is safe to use before I query it Medium
Data Owner Receive alerts when my datasets are accessed or modified I maintain visibility and accountability for my data assets Medium
06 · Competitor Analysis

The Market

Feature Alation Collibra Atlan DataHub OpenMetadata
Auto-discovery ✓ ~ ✓ ✓ ✓
Data Lineage ✓ ✓ ✓ ✓ ✓
Quality Checks ~ ~ ✓ ✕ ✓
Collaboration ✓ ✓ ✓ ~ ✓
API-first ~ ✕ ~ ✓ ✓
Open Source ✕ ✕ ✕ ✓ ✓
Data Glossary ✓ ✓ ✓ ~ ✓
Key Design Decisions

How we decided

Three decisions shaped everything that followed. Each started with a genuine fork. Competing approaches with real tradeoffs. Here's the problem, the options, what we chose, and why.

Decision 01
Unified Search vs. Per-Entity Search Pages
Option A, Rejected. Separate search interfaces per entity type, tables search, dashboards search, pipelines search. Follows the mental model of "I already know what I'm looking for."
Option B, Chosen. One unified global search with entity-type filters and inline contextual previews. Mirrors how data professionals actually begin a discovery session, with a concept, not a category.
Reasoning
Discovery sessions start with a concept, not a category. Asking users to choose a search context before they search assumes knowledge they're trying to gain. Unified search with smart entity filters lets intent drive the journey. The engine surfaces what's relevant, not what the user was forced to pre-categorize.

Discovery sessions start with a concept, not a category. Asking users to choose a search context before they search assumes knowledge they're trying to gain. Unified search with smart entity filters lets intent drive the journey. The engine surfaces what's relevant, not what the user was forced to pre-categorize.
Decision 02
Flat Navigation vs. Role-Based Contextual Navigation
Option A, Rejected. One unified navigation structure serving all user types equally. Simpler to build and consistent, but forces every user through the same primary path regardless of role.
Option B, Chosen. Navigation that adapts primary sections to the user's function. Engineers land at the catalog; governance leads land at policy dashboards; analysts land at their activity and certification feeds.
Reasoning
A governance lead's starting context is completely different from a data engineer's. Flat navigation meant everyone started in a place that was the right place for someone and the wrong place for most. Role-based navigation adds zero complexity for users, they simply arrive where their work lives, while eliminating the daily friction of navigating past irrelevant primary sections.

A governance lead's starting context is completely different from a data engineer's. Flat navigation meant everyone started in a place that was the right place for someone and the wrong place for most. Role-based navigation adds zero complexity for users, they simply arrive where their work lives, while eliminating the daily friction of navigating past irrelevant primary sections.
Decision 03
Force-Directed Graph vs. DAG Left-to-Right Lineage Layout
Option A, Rejected. Force-directed graph where node positions emerge organically from relationship weight. Visually dynamic and handles complex graphs, but spatial positions are arbitrary and can shift on re-render.
Option B, Chosen. Directed acyclic graph with fixed left-to-right flow: sources on the left, transformations in the middle, consumers on the right. Consistent spatial logic that matches how engineers think about data pipelines.
Reasoning
Data engineers think in pipeline terms, data flows left to right. A force-directed layout looks sophisticated in demos but disorients users who expect to trace a directional flow. The DAG constraint makes even complex graphs readable because spatial position carries semantic meaning: left is upstream, right is downstream. Every trace interaction becomes intuitive once that axis is fixed.

Data engineers think in pipeline terms, data flows left to right. A force-directed layout looks sophisticated in demos but disorients users who expect to trace a directional flow. The DAG constraint makes even complex graphs readable because spatial position carries semantic meaning: left is upstream, right is downstream. Every trace interaction becomes intuitive once that axis is fixed.
Final Design

The Platform

A unified data catalog with intelligent search, interactive lineage visualization, and role-based navigation. Every interaction designed around how data professionals actually think, not how data is stored.

sandbox.open-metadata.org
OpenMetadata · Main View

OpenMetadata, Data Catalog Explore View

OpenMetadata · Screen 2
OpenMetadata · Screen 3
OpenMetadata · Screen 4
Design Highlights

Five systems,
one experience

Unified Catalog with Semantic Search
Problem
No single place to search across warehouses, BI tools, pipelines, and ML models. Engineers relied on tribal knowledge to find the right dataset.
Approach
Semantic search engine with entity-type filtering, relevance scoring, freshness indicators, and inline contextual previews, accessible from one search bar.
User Benefit
Discovery time dropped from 2.5 hours to under 20 minutes. Engineers find the right dataset without knowing which system it lives in.
Business Benefit
40% reduction in data-related support tickets. Faster onboarding for new data hires, 3x vs. industry baseline.
Interactive Data Lineage Graph
Problem
A single schema change silently broke downstream dashboards. Teams had no way to see the blast radius of a change before making it.
Approach
DAG-based lineage with collapse/expand, upstream/downstream isolation, impact path highlighting, and inline freshness status, all within the catalog record.
User Benefit
Engineers trace impact paths in seconds before any schema change. Governance leads see cross-system data flows in a single, consistent view.
Business Benefit
Faster incident response for pipeline failures. Enables proactive governance rather than reactive fire-fighting after a breakage.
Role-Based Personalised Dashboard
Problem
Engineers, analysts, and governance officers needed completely different starting contexts but the same navigation forced everyone through identical primary paths.
Approach
Navigation adapts to the user's function on first load, surfacing the most relevant entities, quality signals, and activity feeds per role, with full catalog access always available.
User Benefit
Users arrive where their work is. No daily friction of navigating past irrelevant sections to reach primary workflows.
Business Benefit
Higher daily active usage and better adoption across all three user segments. Lower time-to-value for new users within the first week.
Marketing Website (open-metadata.org)
Problem
The site needed to convert two different buyers simultaneously: technical evaluators (CDOs, senior engineers) and business stakeholders, with fundamentally different language and concerns.
Approach
Layered conversion architecture, business value and governance positioning above the fold; integration directory and API-first proof points for technical evaluators below it.
User Benefit
Technical evaluators find integration depth quickly. Business buyers see compliance positioning without having to read documentation.
Business Benefit
Shorter time-to-trust for enterprise procurement. Clearer documentation onboarding funnel reduced time-to-first-value for new deployments.
Documentation-Integrated In-App Help
Problem
Users left the application to search docs, interrupting their flow at the exact moment they needed help most. Enterprise data tools have steep learning curves that external docs don't solve in context.
Approach
Contextual help panels, inline tooltips, and deep-linked documentation that activate at point of need. Built as a design system component so engineering could wire it to any entity type.
User Benefit
Help appears in context without page abandonment. New users learn while doing. Documentation that gets read because it shows up in the moment of confusion.
Business Benefit
Lower support burden. Documentation component scales across entity types without additional design resources per feature shipped.
Design System

Built for enterprise scale

A complete component library and design token system built specifically for enterprise data UI. Covering data visualization, entity cards, lineage components, form patterns, and status indicators.

Color System
--accent-blue Primary action, links, active state
--accent-cyan Source nodes, data flow, secondary
--accent-violet Sink nodes, output states
--status-fresh Data freshness, certified, healthy
--status-stale Stale data, warning state
Typography Scale
48px Display
32px Heading Serif
20px Section Title
14px Body Regular, Space Grotesk
12px entity.table_name, Monospace
10px LABEL / METADATA TAG
Component Samples
PII Certified Analytics Financial ML
Fresh, Updated within SLA
Stale, Exceeds freshness threshold
Unknown, No freshness data
Spacing & Grid
4 / 8 / 12 / 16 / 24 / 32 / 48 / 64 · Base 4px grid
Entity Icon System
Table
Pipeline
Dashboard
ML Model
Topic
Measured Impact

Design that
moves the metric

50K+
Active Users
Monthly active users across enterprise and open-source deployments
3x
Faster Discovery
3x improvement in data discovery speed post-redesign, measured by user sessions
500+
Integrations
Native integrations with data warehouses, BI tools, pipelines, and ML platforms
40%
Fewer Support Tickets
Reduction in data-related support tickets, attributed to improved discoverability
Key Learnings

What this project taught me

OpenMetadata was one of the most technically complex and politically nuanced design problems I've worked on. Four things became true in ways I didn't fully anticipate at the start.

01
Trust is the real product, not speed
The biggest IA win wasn't making search faster. It was making results feel trustworthy. Freshness indicators, certification badges, and visible data ownership changed user behavior more than any query performance improvement. People don't act on data they don't trust, no matter how fast you surface it.
02
Governance UX is a political problem wearing a design hat
Data governance tools are resisted because they feel like surveillance imposed on producers for the benefit of compliance teams. When we reframed governance features as giving data owners more visibility and attribution. Rather than taking away autonomy, adoption followed. The interface didn't change much. The framing did everything.
03
Heterogeneous audiences demand layered IA, not consensus design
You cannot design one interface that averages across a data engineer, a data scientist, and a CDO. Averaging produces something that serves no one well. The right answer is layering. A shared underlying structure that surfaces different primary paths per role. That requires more upfront architecture work but produces genuinely better adoption across every segment.
04
Open-source shifts your test group to thousands, simultaneously
The community surfaced IA problems within days of each release that no internal usability test would have caught. Engineers filing issues in GitHub were doing free, high-signal usability research. The lesson: design for the public changelog. Every interaction decision needs to survive being read by someone who has used 15 other tools in the same category and will compare you to all of them immediately.
Research, personas, flows & the thinking underneath · The long version · 6 sections · the reasoning behind every decision above
“

"OpenMetadata had the kind of scope that is genuinely humbling. 600+ data sources, six product pillars, two completely different user audiences, and a team that had already built tools used at Uber and Netflix. The design problem wasn't making it look good. It was making it immediately legible to a data engineer who has seen every enterprise dashboard ever built and is deeply skeptical of all of them. That audience gap between 'I helped build Apache Hadoop' and 'I need to find where this dataset came from' is one of the hardest IA problems I've worked on. I don't think we fully solved it. But we made it considerably better."

Rupesh Chavan, Lead Product Designer
Explore more
All case studies All featured work Next: Collate.io, Enterprise SaaS / Data