Problem
BYO was powerful, but it behaved like an internal tool:
- Testing was slow and painful
- Errors and state were hard to interpret
- Critical actions were buried or required copy/paste loops
- Custom code patterns were inconsistent across the product
The real issue was not capability. It was confidence. Users were being asked to do developer-grade work in an interaction model that made mistakes feel likely and expensive.
"Much of it is user experience... the same things that people have complained now for over two years on usability."
Internal review, Nov 2025
"The flow to do that is really counterintuitive... you need to put a file path... hard-coded... then copy/paste."
Internal review, Oct 2025
"The test here is slow and painful... you can't debug... error message is not easy."
Internal review, Oct 2025
Context
The first version used a right-side drawer because it was fast to build on top of an existing panel pattern. That decision lowered early implementation risk, but it broke down in real use.
- There was too little space for real code work
- Documentation and controls competed for the same area
- The overall interaction model became brittle and overly modal
In practice, the setup flow forced repeated context switches before users could validate intent. File access, testing, configuration, and reusable processor selection all lived in separate moments with weak connective tissue.
Approach
I treated the redesign as a workflow architecture problem, not a polish pass. The core design decisions were:
- Promote custom code to a primary task instead of a side-panel detail
- Keep runtime feedback and results visible while users edit
- Use the right rail for contract and runtime configuration only
This created a workspace model that better matched how developers actually think: orient, edit, validate, adjust, and repeat.
Discovery and Evidence
Two additional structural decisions came out of review and prototype work.
First, new flows needed visible guidance on the canvas itself. Users should not have to infer the correct setup sequence from empty space, so new flows begin with a Source -> Code -> Destination scaffold.
Second, the product needed one stable editing model after the initial choice of whether to write new code or select from a reusable library. The mode branch could be explicit, but the experience after that needed to stay predictable.
Solution
The shipped direction combined three changes:
- A full-screen, developer-grade workspace with code editor, console feedback, and contract/runtime rail
- Template-first flow guidance that made the next step obvious on the canvas
- An explicit "write new" vs "select from library" decision that resolved into one stable editing model
"We have multiple patterns in the UI in how we handle the custom code... we need a consistent pattern."
Internal review, Nov 2025
"When I go to provide your own function, we have some code already... Half the screen is documentation... confusing."
Internal review, Nov 2025
The design move was to make the choice explicit up front, then keep users in a single, stable mode with clear CTAs and fewer impossible states.
Implementation
I partnered with engineering around the parts of the workflow where design clarity directly affected feasibility:
- Selecting files from the chosen folder instead of copying paths manually
- Keeping folder context visible while coding and testing
- Defining a state model so valid transitions, warnings, and CTAs stayed coherent
This mattered because the experience needed to be defensible both in the product and in the implementation handoff. The interaction model could not be hand-wavy if the workflow was going to ship cleanly.
Results
The redesign changed BYO from "works on paper" to a workflow teams could align on, prototype against, and ship with confidence.
- Hidden actions were reduced and the path to a successful test became easier to understand
- Handoff quality improved because state transitions and runtime expectations were explicit
- The v1 scope became more credible because the workflow model was clearer
Reflections
The strongest lesson was that developer UX is not just another form problem. Once code became a primary task, the product needed a workspace model, a reliable state model, and defaults that reduced uncertainty without hiding control.
That combination improved trust more than any isolated visual change could have.