From JSON editor to self-serve data layer

Context

My role

As the squad's first dedicated designer, I owned design from discovery through delivery and helped shape the project's direction with Product and Engineering.

The team had explored some directions before I joined. I took responsibility for clarifying the user problem, developing and testing solutions, and carrying the design through implementation.

I used customer testing to challenge the proposed SQL approach, reviewed feasibility with engineers, and worked through tradeoffs between customer autonomy, flexibility, and the risk to existing configurations. Alongside delivery, I established how design worked within the squad, including customer validation and collaboration with the PM and engineers.

The problem

Finance teams couldn't own their own data

When I joined, working with data meant editing JSON directly. There was no UI to guide users or abstract the underlying structure, and the squad's engineers had to step in every time something changed.

But early explorations had already started, and I ran a first round of user tests to understand where the real friction was. Three customers walked through the flows. What came back was more nuanced than "the UI is confusing."

The core issue was a language mismatch. Users expected to work with dimensions, mappings, and date formats but the interface was giving them data types and schema configuration. For an FP&A team the difference between something that feels like their tool and something that feels like a developer's tool they've been handed matters.

One participant flagged restrictions caused by dataset dependencies, missing validation when creating dimension names, and uncertainty about what happened to data after mapping.

That shaped how I prioritised. The problem went deeper than missing UI: the system was exposed at the wrong level of abstraction, and users had no way to reason about what was happening to their data or trust that it was correct.

Approach

Evolving the system without breaking it

The system was already in use. We had to improve it without breaking existing customer configurations, so the work moved forward in stages.

SQL was the squad's first choice for transformations. Engineers knew it well, but I argued against exposing it to finance users. It would introduce another language alongside the formulas they already used in Abacum's modeling layer. Testing supported that concern: participants could express the transformation logic with Excel functions but struggled to do the same in SQL.

The squad decided to ship SQL as an interim solution so we could move forward while building the custom formulas. I disagreed with that initial choice. The formula-based column builder shipped later, bringing transformations closer to the language users already knew.

The interface needed a similar shift. Finance teams thought in dimensions, mappings, and column formats, while the system exposed data types and schema configuration. I worked on translating that technical structure into their vocabulary.

We also constrained some operations in early iterations to prevent invalid configurations from affecting downstream models. That reduced flexibility, particularly for advanced cases, but gave users a safer way to configure their data.

Solution

Introducing a usable layer on top of a flexible system

The core change was a guided interface over JSON-based dataset configuration. Finance teams could work with dimensions, mappings, and column formats instead of editing the underlying configuration directly.

The column builder let users select a column, define a transformation, reference other fields, and check whether the configuration was valid. Constraints helped prevent invalid configurations from affecting downstream models.

The formula-based version brought transformations closer to the language users already knew from spreadsheets and Abacum's modeling layer.

Example

Creating a calculated column

Converting revenue into a common currency shows the change from JSON configuration to the shipped column builder.

Before

Teams edited JSON directly. Creating a calculated column meant writing a configuration object by hand:

JSON

{
  "column": "revenue_usd",
  "formula": "revenue * exchange_rate",
  "type": "number"
}

Finance teams needed engineering support to write or review the transformation.

After

Users could define the transformation in the column builder, reference existing fields, and check whether the configuration was valid.

The guided interface supported standard configuration with fewer opportunities for invalid input. Some advanced transformations remained restricted or required additional steps.