Designing Safer Data Configuration Workflows for Enterprise Reporting

Objective

The Data Hub manages two things: what data exists in the system (Data Dictionary) and what that data means to the business (Key Definitions). Changes in either area could silently break the other.

The work focused on:

What Wasn't Working

Three patterns came up consistently across conversations with the product team, engineers, and administrators.

High-impact actions behaved like simple toggles

Admins described the same pattern: make a change, assume it went through, 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 all used the same simple UI interaction.
• Any of these could affect downstream reports, drill-downs, and metric definitions without warning.
• The system surfaced no indication of what depended on a column or definition before the action was taken.

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.
• This made the system feel unreliable even when the underlying data was correct.

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. Key Definitions controlled business meaning.
• The two surfaces were disconnected. An admin could update one without any visibility into how it affected the other.
• This hid dependencies between columns and definitions, tables and metrics, relationships 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.

I focused the design on making consequences visible before damage occurred.

Design Approach

I approached the Data Hub as a system, not a collection of screens. Every decision I brought to review was grounded in one question: how clearly does this surface the consequence of an action before it's taken.

This was a two-designer project with a PM and two developers. Most structural decisions came out of working sessions with the PM and senior engineer who understood the edge cases. My role was translating those constraints into interface decisions.

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.

D KD

Dictionary list page

A toggle suggests a low-stakes, reversible action. Disabling a column is not. A column referenced in a Key Definition, metric, or drill-down path does not fail gracefully when removed. It fails silently, or throws a generic error somewhere downstream that looks unrelated to the change.

The system's response was an error toast after the fact. It told admins the action failed, not what depended on the column or what would need to change first.

What I redesigned - Dictionary

Before After

Use slider to switch between old and redesigned dictionary page.

The column list stayed structurally intact. The work focused on what happened when an admin tried to disable a column already in use.

I designed a contextual warning to appear at that moment: which definition references the column, why the action is blocked, and what the admin needs to resolve before disabling it becomes safe. The failure is no longer a dead end.

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 encode business logic that teams have aligned on, and they need to be configured explicitly.

Before the redesign, Key Definitions existed as a configured list. Admins could enable or disable them and see descriptions. What they could not see was what data each definition depended on, how it was calculated, or what would break if they changed it. Understanding that required reading the underlying query.

Definition Configure Screen

I redesigned definitions as inspectable, traceable objects, not just named configurations.

What I redesigned - Definitions

Three decisions defined the Key Definitions work:

Natural language formula input. Admins previously had to write definitions in structured query syntax, which locked out anyone without a technical background. I replaced this with a plain language formula field, removing the translation step between business intent and system configuration.

Source visibility. The columns powering a definition were invisible in the original interface. I surfaced them directly in the configuration panel: field name, table, data type, and description. I also separated fields the admin selected from those inherited through connected definitions, so the boundary is clear.

Merge path selection. When a definition spans multiple tables, the join path determines what it calculates. This logic was completely hidden before. I made it an explicit step: suggested paths ranked by relevance, with a visual graph showing the exact join chain before the admin saves.

Merge path selection was the most technically opaque part of the old system and the most common source of confusion during setup. Making it visible before committing was the clearest example of the project's central idea.

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: 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.

Merge Path Selection

How Data Dictionary and Key Definitions Work Together

The two surfaces were always connected. My goal was to make that connection visible inside the interface.

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 are not edge cases. They are the normal operating conditions of a system where structure and meaning are managed in separate places but depend on each other completely.

Making that dependency visible, and surfacing it at the right moment in each workflow, was the through-line of the entire project.