Code editor for advanced data transformation

Initial company and product state

Company state‍

Celigo was a Series B SaaS startup, and I was the first product designer. The platform’s success depended on enabling customers to build and maintain complex data integrations independently, without relying on professional services. Its current Gartner position was Niche, though it would move to Leader.

Product state

‍Flow creation was the core of the product’s value, but developers needed to write external scripts to perform advanced data transformation. In order to keep developers in the platform, as well as enable them to test their scripts directly in their flows, we needed to add a robust code editor.

Challenge

The platform had no way to write or test scripts in-product, forcing developers into external tools and breaking their workflow. Expectations were high—most users relied on VS Code, and the editor needed to support complex JSON structures, linting, error visibility, and debugging without overwhelming business users.

Approach

I conducted research with developers, studied leading editors like VS Code, and identified an exhaustive list of scripting use cases. I then distilled this into a focused, high-impact feature set: IntelliSense, JSON structure handling, auto-formatting, tag/handlebar autoclose, linting, in-line error indicators, search/replace, reference panels, layout options, and more—all within a streamlined UI aligned to the platform’s mental model.

The result: a code editor purpose-built for complex data transformation inside an enterprise automation platform—powerful enough for engineers, but approachable for non-developers.'

Key design decisions

Data → Data tranformation → Output (mental model)

Users needed to see what their work was doing. The editor supported a multi-panel UI where they could:

• View incoming data
• Write or adjust scripts, with IntelliSense to reduce scripting errors
• Create or modify data transformation rules
• Instantly preview transformed output

This reduced guesswork and let users validate logic in seconds instead of testing in production.

Details

1. Dual-pane understanding of data → script → output
   Users could view incoming data, write or adjust their script, and immediately preview how the output would change—reducing guesswork and validating logic in seconds.
   ‍
2. A streamlined “Rules” mode for non-developers
   For simpler use cases or less technical users, I designed a Rules tab that mapped incoming fields to destination fields without needing to write code at all.
   ‍
3. XML template editing with live preview
   Users could build XML templates and instantly preview how their script transformed the structure.
   ‍
4. Built-in help & IntelliSense
   To eliminate memory load, the editor included a reference panel listing all objects, functions, and fields that could be used, along with inline IntelliSense to guide usage.
   ‍
5. Inline validation & auto-preview
   Users could toggle auto-preview on/off while benefiting from linting, inline error markers, autocomplete for tags/handlebars, and paired-element highlighting.
   ‍
6. JSON-aware visual modes
   Both incoming and outgoing data could be toggled between raw and tree view, improving clarity for nested or complex structures.
   ‍
7. Layout and workflow flexibility
   Vertical/horizontal layouts, search and replace, and code formatting ensured the editor felt natural to developers accustomed to modern IDEs.
   ‍

Scripting mode

Users could see what their data looked like, as well as their script, then view how that impacted the data going out. They could also search within each panel, copy, switch displays and modes, and cancel script changes.

Rules mode for simpler data transformation

Not every user wanted to write code, nor did every flow require complex data transformation. I designed a Rules mode that let users map fields visually without scripting, making data transformation accessible to business and operations users.
‍

XML template

Users could also write XML template and preview how the data would be impacted.

Help panel

In addition to inline help while scripting, a later iteration provided available functions, fields, lookups and more, further eliminating guesswork.

Auto-preview & inline help

Users could choose to see changes as they coded or only preview changes on-demand. Inline help guided users through exactly the formatting they needed to use, eliminating guesswork.

JSON tree view

Users could switch their data view from expanded to collapsed JSON representations.

Final design

We were able to move away from the large toggle switches between editor modes and rules/scripts view in favor of an icon toolbar. Users could switch from scripting to rules mode.

Impact

The new editor:

• Kept developers in flow and eliminated external tool-switching
• Reduced broken automations by surfacing help and inline validation, as well as preview and testing rules and scripts
• Enabled non-developers to complete transformation work independently
• Increased development velocity and accuracy across complex integration workflows

It transformed scripting from trial-and-error into a guided, efficient, and confident experience—directly improving implementation success and platform adoption.