piyush

kulkarni

Home

Designing the System Layer That Protects Reporting Integrity

Reimagining Petavue’s Data Hub to make structural and semantic data changes predictable, traceable, and safe.

Petavue is a B2B AI analytics platform built for RevOps and data teams. At its core, the product helps companies trust their reporting, but that trust depends entirely on how well the underlying data is configured. The Data Hub is where that configuration happens. It's where admins define what data exists, what it means to the business, and how it connects to every report, metric, and dashboard in the product. When it works well, it's invisible. When it doesn't, reports break in ways that are hard to trace and harder to explain.

By the time this project started, the Data Hub was functional but fragile. Admins could make changes that looked routine but caused failures they wouldn't discover until something downstream broke. The work was about closing that gap and making the system's consequences visible before damage occurred.

Team

2 Designers

1 Product Manager

2 Developers

Role

Industry

Product Design, Visual Design, Design System, User Flows, Prototyping

Tech Stack

Figma

Date

2024 - Current

Data Hub

Objective

Re-design the Data Hub as a reliable system layer where changes to data structure and meaning are predictable, explainable, and safe.

At its core, it answers two questions:

What data exists in the system
What that data means to the business

These questions are handled by two equal pillars.

The work focused on:

Making the impact of Data Dictionary changes visible before they break reports

Turning Key Definitions into inspectable, shared representations of business logic

Reducing hidden dependencies between structure, meaning, and reporting

Helping admins move fast without causing silent failures downstream

Use slider to view Dictionary and Definitions page.

Use slider to switch between different modes

What Wasn’t Working

The Data Hub allowed admins to make powerful structural and semantic changes, but the system gave little visibility into their downstream impact. As a result, small configuration updates could unexpectedly break reports across the product.

1. High-impact actions behaved like simple toggles

We saw this pattern in how admins described their workflow. They'd make a change, assume it went through, and only find out something broke when a report failed hours later. The action and the consequence were separated by time and context.

Disabling a column, removing a relationship, or updating a definition were treated as routine UI actions.

In reality, these changes could affect multiple downstream reports, drill-downs, and metric definitions.

Because the system did not surface these dependencies beforehand, admins often discovered the impact only after reports failed.

2. Failures were disconnected from their cause

This came up repeatedly when engineers got pulled in to debug. The troubleshooting process always started with the same question: what changed recently? The system had no answer.

When a report failed, users saw generic execution errors.

There was no clear path back to the change that triggered the failure. Troubleshooting meant manually investigating tables, columns, and definitions to identify the issue.

This made the system feel unreliable even when the underlying data was correct.

3. Structure and meaning were separated

Admins managing definitions often didn't know which tables or columns they were drawing from. That information lived in the underlying query, readable only if you knew what to look for.

The Data Dictionary controlled structure, while Key Definitions controlled business meaning.

However, these surfaces were disconnected. Admins could update one without clearly seeing how it affected the other.

This separation hid critical dependencies between:

tables and definitions
columns and metrics
paths and drill-downs

The Core Insight

The biggest risk in the Data Hub was not incorrect data. It was invisible impact.

Correct changes could still break reports.

Valid updates could silently disable definitions.

Failures appeared far away from their cause.

We focused on making consequences visible before damage occurred.

Design Approach

We approached the Data Hub as a system, not a collection of screens.

Instead of redesigning individual pages in isolation, we focused on how changes in one part of the Data Hub affect the rest of the product.

Every decision was evaluated based on how clearly it surfaced dependencies and how predictable the outcome felt to the user.

The approach centered on three principles:

01 Surface impact before execution

High-impact actions like disabling tables, columns, or paths should never behave like silent toggles.

The system now shows what reports, definitions, and drill-downs depend on a change before the admin confirms it.

02 Make dependencies inspectable

Relationships between sources, tables, columns, and definitions are now visible inside the interface.

Admins can trace how data flows from structure to meaning and understand what a change will affect.

03 Treat structure and meaning as one system

The Data Dictionary controls data availability.

Key Definitions control business interpretation.

This was a two-designer project with a PM and two developers. Most structural decisions, what to surface, where to intervene, how much friction to add, were made collaboratively with the PM and senior developer who understood the edge cases better than anyone. My role was translating those constraints into interface decisions, finding the design pattern that matched the technical reality without overwhelming the admin with complexity they didn't need to see.

Understanding the Data Dictionary

The Data Dictionary is where admins manage everything the system knows about data — sources, tables, columns, relationships. Every report, chart, and metric in Petavue depends on decisions made here. It is not a settings page. It is the foundation.

The existing screen did a reasonable job of presenting information. Tables were organized in a left-side nav, columns were listed with data types, descriptions, and sample data, and a toggle on each row controlled whether a column was available for analysis. On the surface, it looked functional.

Dictionary list page

The problem was in what the toggles implied.

A toggle suggests reversibility. It suggests low stakes — flip it one way, flip it back. But disabling a column in the Data Dictionary is not a low-stakes action. A column used in a Key Definition, a metric calculation, or a drill-down path does not fail gracefully when removed. It fails silently, or it throws a generic error somewhere downstream, disconnected from the action that caused it.

The current system's response to this was an error toast — a small notification that appeared after an admin tried to disable a column already in use. It told them the action couldn't be completed. It did not tell them why the column mattered, what depended on it, or what would need to change before disabling it became safe.

This is a reactive pattern dressed up as a safeguard. The admin still had no picture of the system they were operating inside.

What we redesigned

Use slider to switch between old and redesigned dictionary page.

Use slider to switch between different modes

The column list itself remained structurally intact — the information architecture was sound and admins were already familiar with it. The work focused on what happened the moment an admin attempted to disable a column that was in use.

Previously, that moment produced nothing. The toggle would fail, or the system would behave unpredictably, with no explanation surfaced. Admins had no way of knowing whether their action had taken effect, been silently blocked, or caused something to break elsewhere.

The redesign introduces an error toast at that moment — a direct, contextual signal that tells the admin the column cannot be disabled because it is currently referenced in a definition. It stops the action from going through silently and gives the admin something to act on. The failure is no longer invisible.

Key Definitions The language layer

If the Data Dictionary answers "what data exists," Key Definitions answer "what does it mean." Metrics like ARR Booked, Risk Customer, or Average Sales Cycle Length are not self-evident — they encode business logic that teams have aligned on, and they need to be configured explicitly. Without that, the same term gets calculated differently across teams, and reports stop being comparable.

Before the redesign, Key Definitions existed as a configured list. Admins could enable or disable them, and they had descriptions. What they didn't have was transparency — no visibility into what data a definition depended on, no way to understand how it was calculated without decoding the underlying query, and no signal when an edit to one definition or its source columns would affect something downstream. Changes were made and saved, and a toast appeared after the fact. The definition might still run. It might return wrong results. There was no way to know without checking.

Definition Configure Screen

The redesign treated definitions as inspectable, traceable objects — not just named configurations.

What we redesigned

Three decisions defined the Key Definitions work:

Natural language formula input. Admins previously had to express definition logic in structured query syntax — a bottleneck that locked out non-technical users. The redesign replaced this with a plain language formula field. Admins describe the logic; the system interprets it.

Sources as an inspectable layer. The columns powering a definition were previously invisible to the admin. The redesign surfaces them explicitly — field name, table, data type, description — and separates user-picked columns from those inherited through connected definitions. This didn't exist before.

Merge path selection. When a definition spans multiple tables, the join path between them determines what it calculates. The redesign surfaces this as an explicit choice — suggested paths ranked by relevance, with a visual graph confirming the exact join chain before the admin commits.

Merge path selection was the most technically opaque part of the old system. When a definition spanned multiple tables, the join path between them was chosen automatically and invisibly. Admins had no way to know which path the system had picked, whether it was the right one, or what it would produce. In practice this meant definitions could return subtly wrong results with no indication that anything had gone wrong.

The redesign surfaces this as an explicit choice. Suggested paths are ranked by relevance, and a visual graph confirms the exact join chain before the admin commits. It's a small surface but it represents the core principle of the entire project. Consequences should be visible before the action is taken, not discovered after.

Merge Path Selection

Impact

Before the redesign, configuring or editing a Key Definition reliably required an engineer in the loop. The syntax barrier alone meant RevOps admins couldn't self-serve on changes that were conceptually simple, like updating a formula, swapping a column, or adjusting a join path.

After the redesign, admins could handle these changes independently. The natural language input removed the technical bottleneck. Explicit source visibility meant admins understood what their definitions were drawing from without needing to read a query. Engineering involvement dropped for routine definition work, and new admins could orient themselves through the interface rather than through documentation or a walkthrough.

Merge Path Selection

How Data Dictionary and Key Definitions Work Together

The two surfaces were always connected. The redesign just made that connection visible.

A column disabled in the Dictionary can break a Definition. A Definition drawing from the wrong join path can corrupt every report that uses it. These aren't edge cases — they're the normal operating conditions of a system where structure and meaning are managed separately but depend on each other completely.

The work across both surfaces was guided by the same principle: consequences should be visible before damage occurs, not discovered after.

Making this propagation visible — and intervening at the right points along it — was the through-line of the entire project.

Reflection

The feature shipped in a better state than it started. Admins had visibility they didn't have before, the dependency between structure and meaning was no longer hidden, and the system's most dangerous actions were no longer silent. That's the version of done that was possible in this phase.

Two things remain unfinished in ways worth naming, not as gaps in the design, but as the natural boundary of what this project could scope.

The error toast was the right first move. Surfacing silence matters more than surfacing it perfectly. But a toast is still a dead end. It stops the action without creating a path forward. The next version needs to go further, show what's affected, link to the dependencies that need resolving, and let the admin act from that same surface without losing their place. The feedback loop isn't closed yet.

The second gap is notifications. The Data Hub is not a one-admin system. When one admin changes a definition, others working on connected definitions have no way of knowing something upstream shifted. A notification layer would complete the system's ability to communicate across sessions, not just within them. It was scoped out. It should come back.

6:45 PM