Case Studies
Slide Templates

BYO Code Flows

Turning an SA-assisted capability into a self-serve workflow

Mike - Product Design | Nexla | Oct-Dec 2025

Problem (what field evidence showed)

BYO behaved like an expert-only capability:

  • Code lived inside source config and was hidden from the DAG
  • Testing depended on hard-coded file paths and copy/paste loops
  • Status and troubleshooting required too much tribal knowledge
  • Customer-facing teams still did too much of the workflow for users

Solution (what I pushed into the design)

Treat BYO as a first-class workflow:

  • Make code visible in the flow itself
  • Promote authoring into a focused workspace
  • Stabilize write-new vs library paths
  • Bring testing, file access, and feedback closer to the code

Outcome (what changed directionally)

The design moved the product toward self-serve use:

  • Clearer source -> code -> destination model
  • Stronger implementation handoff
  • Reusable workflow patterns for future code-heavy surfaces

Context: Who BYO Served and What Had to Change

Primary users

  • Data engineers
  • Platform engineers
  • Solutions architects

What good had to look like

  • Users understand where code lives in the workflow
  • Users test with real files without brittle copy/paste
  • Users can see state and recover from failure without expert help
Mental model flow showing source to BYO code to destination

What the Customer-Facing Evidence Actually Said

The problem was repeated confusion in core workflow moments, not isolated UI complaints.

The flow to do that is really counterintuitive because you need to put a file path here, which needs to be hard-coded.

Customer/SA walkthrough (BYO Gabriel 2025-10-21)

As a first-time user who is self-serving, this is super confusing because I don't know whether I should click on run now.

Customer/SA walkthrough (BYO Gabriel 2025-10-21)

Ideally, we want to get to a state where customers don't need our help to do everything.

Customer/SA walkthrough (BYO Gabriel 2025-10-21)

Decision 1: Make the Processing Step Legible in the Workflow

What field feedback made clear

  • The processing logic was the central task but was buried in source setup
  • Users could not tell whether the custom code was a source setting or a first-class step
  • Making code visible on the DAG improved the mental model immediately

Why this mattered

  • It reduced hidden logic
  • It made the transform feel intentional instead of accidental
  • It gave the team a clearer object to design around
Flow guidance showing source, code, and destination as explicit steps

Decision 2: Promote BYO from Drawer to Workspace

Why the drawer model failed

  • Too little room for real code and runtime configuration
  • Documentation, controls, and output competed in one narrow space
  • The workflow felt modal and brittle instead of grounded

What the workspace changed

  • Code became the primary task
  • Console and results stayed visible
  • Contract and runtime configuration moved to a supporting rail
BYO full workspace editor with code, console, and supporting configuration

Decision 3: Keep the Authoring Model Stable

Make the choice explicit, then keep users in one predictable editing model.

  • Write new generates a stub and makes the code contract explicit
  • Select from library previews code before insert instead of switching into a different mental model
  • State-machine logic prevents impossible transitions and inconsistent CTAs
  • The goal was fewer surprises for users and fewer edge cases for engineering

Decision 4: Bring Testing and Troubleshooting Closer to the Code

Remove avoidable copy/paste loops and make failure easier to interpret.

You cannot just select it from here and test it right away. You need to put a file path here, which needs to be hard-coded.

Customer/SA walkthrough (BYO Gabriel 2025-10-21)

Where do I go? Like from here, where do I go? I don't know.

Customer/SA walkthrough (BYO Gabriel 2025-10-21)

This is really confusing because we don't even have a badge.

Customer/SA walkthrough (BYO Gabriel 2025-10-21)

How I Coached the Work Through the Team

How I drove clarity

  • Started with customer and SA walkthroughs before solutioning
  • Used prototypes so stakeholders reacted to behavior, not abstract opinions
  • Named v1 versus later tradeoffs with product and engineering leadership
  • Moved from narrow conversations to wider team share-outs and feedback loops

Why that mattered

  • It reduced hand-wavy ambiguity
  • It exposed edge cases earlier
  • It made the interaction model easier for the whole team to own
Design journey timeline showing progression from field evidence to refined workflow

What Changed, and What I Would Measure Next

Directional outcomes now; explicit measurement frame for launch and follow-through.

Directional outcomes

  • Clearer happy path and fewer hidden actions
  • Stronger handoff through explicit state and contract decisions
  • A more teachable workflow for customers, PMs, and engineers

Measurement frame

  • Time to first successful test
  • Support-free BYO creation rate
  • Actionable error visibility
  • Reuse split: write new versus library
Measurement frame: do not invent the metric until the product can actually observe it

What I Would Carry Forward

Elegant workflow design in technical products starts with legibility, not ornament.

  • If users cannot see where the logic lives, they cannot build confidence in it
  • Testing and troubleshooting are part of interaction design, not postscript utility work
  • The strongest coaching move was widening the review surface so the team could reason about the workflow together

Evidence Inputs

Primary sources behind the case narrative.

  • Customer and solutions architect walkthroughs of real BYO friction
  • Design reviews that exposed mode, state, and testing problems
  • Working sessions that clarified v1 versus later tradeoffs
  • Follow-up reviews and share-outs that widened team ownership