← Back

Transform UX: AI Co-Creator for Data Pipelines

Making AI-powered data transformations feel like a conversation, not a code editor.

Role

Lead Product Designer

Timeline

2023 — 2024

Team

Cross-functional team of 12

At a Glance

Writing data transformations in C3 required deep knowledge of the platform's proprietary expression language. Even experienced data engineers spent hours on transforms that should have taken minutes.

  • -Reduced average time to write a data transform from 45 minutes to under 5 minutes
  • -AI-assisted transforms accounted for 70% of all new transforms within 3 months of launch
  • -Support tickets related to transformation errors dropped by 60%
  • -Onboarding time for new customers decreased from 3 weeks to 4 days

Overview

C3 Transform is the data transformation engine inside the C3 AI Suite. It lets enterprise teams define how raw data becomes usable inputs for AI models. I led the redesign of the transformation authoring experience, introducing an AI-assisted workflow that replaced manual coding with natural language interaction. Users describe the transform they want in plain English and the system generates the expression code. We shipped two major iterations and it became the default way customers build transforms across the platform.

My Role

  • -Led end-to-end design from research through production ship
  • -Ran user research sessions with data engineers at 3 enterprise customers
  • -Designed two major iterations of the AI interaction model (inline widget and chat panel)
  • -Partnered closely with ML engineering on prompt design and response formatting
  • -Presented the final design to C3 AI leadership for go/no-go approval

The Problem

Writing data transformations in C3 required deep knowledge of the platform's proprietary expression language. Even experienced data engineers spent hours on transforms that should have taken minutes. New customers hit a wall during onboarding because they could not write transforms without extensive training. Support tickets about transformation errors were the single largest category in our backlog. The expression language was powerful but obscure. Simple tasks like joining two data sources or filtering by date required syntax that felt nothing like SQL or Python. We were asking users to learn a new language just to do something they already knew how to do.

What I Learned from Users

01

Data engineers described the expression language as "like SQL but none of the patterns transfer" and defaulted to copy-pasting from old projects

02

Most transforms followed a small set of common patterns (joins, filters, aggregations) but the interface treated every transform as a blank-slate coding task

03

Users spent more time debugging syntax errors than thinking about the actual data logic

04

Teams had created internal wikis with transform recipes because the official docs were too abstract

05

Non-technical stakeholders could describe the transform they wanted in plain English but had no way to execute it themselves

06

The biggest fear was not writing the wrong transform but not knowing if it was wrong until much later in the pipeline

The Approach

I started by mapping every transform our top 20 customers had built in the last year. This gave us a clear picture of what people actually needed versus what the tool theoretically supported. About 80% of transforms fell into five categories. That was the opening. If we could make those five patterns effortless, we would cover most real usage. I proposed an AI-assisted approach where users describe what they want in plain language and the system generates the expression code. We prototyped two versions. The first was a compact widget that appeared inline next to the code editor. The second was a full chat panel that supported back-and-forth refinement. We tested both with customers. The widget was faster for simple transforms but broke down when users needed to iterate. The chat panel handled complexity better and gave users more confidence because they could see the AI reasoning. We shipped the chat panel as the primary experience with the widget as a quick-action shortcut.

Key Design Decisions

Visual pipeline canvas as the foundation

Before touching the AI interaction, we needed to make the overall pipeline structure visible. I designed a node-based canvas where each transform is a visual block connected to its data sources and outputs. This gave users a map of their data flow and made it obvious where a new transform should go. The canvas also became the anchor point for the AI panel. You click a node, the AI panel opens with full context about that node's inputs and expected outputs.

Pipeline

Data Pipeline Nodes

AI target selection and smart matching

When users wanted to create a transform, the first step was selecting which data fields to operate on. I designed a target selection flow where the system suggests likely field matches based on the data schema. Instead of scrolling through hundreds of fields, users see a ranked list of recommendations. Selecting a target automatically scoped the AI's context so its suggestions were relevant to that specific field and data type.

Transform Select Target

Transform Selected

V1: Inline AI widget for quick transforms

The first iteration was a compact widget embedded directly in the transform editor. Users typed a plain language request, and the AI generated the expression code inline. It worked well for simple, one-shot transforms like type conversions or basic filters. The widget showed the generated code with syntax highlighting and a one-click apply button. But for anything that required iteration or explanation, the widget felt cramped and users lost track of what they had asked for.

Transform AI Widget

Transform AI Working

AI-generated transforms with diff view

A critical trust issue came up in testing: users did not want to blindly accept AI-generated code. I introduced a diff view that showed exactly what the AI was changing. Before and after, line by line. Users could accept the full suggestion, accept parts of it, or ask the AI to try again. The diff view also highlighted potential issues like type mismatches or null handling gaps. This transformed the interaction from "trust the AI" to "review and approve," which matched how engineering teams already worked with code reviews.

Transform AI Generating

Transform AI Diff

Transform AI Done

V2: Chat panel for complex, multi-step transforms

Based on feedback from the widget version, I designed a full chat panel that lived alongside the code editor. Users could have a back-and-forth conversation with the AI, asking it to refine, explain, or completely rethink a transform. The chat kept full history so users could reference earlier attempts. It also supported validation, showing the user if the generated transform would actually work with their data before they applied it. The chat panel became the primary AI interaction surface and the widget was kept as a shortcut for simple operations.

AI Chat

Transform Diff

Transform Complete

Impact

  • -Reduced average time to write a data transform from 45 minutes to under 5 minutes
  • -AI-assisted transforms accounted for 70% of all new transforms within 3 months of launch
  • -Support tickets related to transformation errors dropped by 60%
  • -Onboarding time for new customers decreased from 3 weeks to 4 days
  • -Increased self-serve pipeline creation by 340%
  • -Directly contributed to closing 2 enterprise deals worth $8M+ ARR

What I Would Do Next

  • -Extend AI assistance to other parts of the pipeline beyond transforms (data source configuration, model tuning)
  • -Add collaborative features so multiple team members can work on transforms simultaneously
  • -Build a transform library where teams can share and reuse proven patterns across projects
  • -Explore proactive AI suggestions that detect common data quality issues before users encounter them