The plan was six weeks to refresh Orbit's pipeline canvas, add automatic node layout and introduce custom themes. Support tickets pointed somewhere else: people could build their flows, but when a run failed they needed help to know where to act. I proposed changing what the release was for, without moving the date.
Orbit is where data teams build and run pipelines: sources, transformations and outputs connected on a canvas. The roadmap item was clear: update the canvas, add auto-layout, add themes.
Reading through support requests changed the picture. Building flows wasn't the problem. Recovering from a failure was. When a run failed, users opened a ticket to ask where to intervene.
I proposed postponing auto-layout and themes, and spending the release on error diagnosis.
This wasn't something extra slipped into the brief. I brought the PM and the tech lead a proposal with three parts: what we'd cut, what we'd ship, and which risk we wanted to reduce. The date stayed the same.
Not “redo the canvas”, but “help people fix a failed run without asking us”.
In the existing UI, every failed node was coloured the same red. A single broken query upstream looked like three independent problems, and the side panel listed three identical “Execution failed” entries. The only clear next step was contacting support.
The most important decision was to separate the first error from the nodes blocked because of it. We highlighted the first error and showed everything downstream as blocked dependencies: greyed out, dashed, waiting on that step. The failure now has one origin and a visible blast radius.
Selecting the first error opens the diagnosis next to the graph: the error message in plain words, the affected configuration, and the logs of the same run, filtered to that node. The graph stays in view, so you never lose where you are.
I gave up on full editing inside the diagnosis panel. It would have stretched the scope too far, and essentially meant rebuilding the editor.
The panel explains the problem and takes you to the right spot in the editor: the existing SQL editor opens at line 14, with the cause and the available columns beside it. Editing stays in the flow people already know. That's what let us ship a complete path, from failure to fix to re-run, without rebuilding the editor too.
To evaluate the release, we linked run events to support tickets.
In a comparison between the four weeks before and the four weeks after, on the same 12 workspaces:
We excluded platform incidents and compared the same error categories. A guide published alongside the release still meant we couldn't credit all of it to the new UI.
The result wasn't “we redid the canvas”. It was choosing to invest in people's ability to fix a problem without depending on support, and postponing two features that were already planned to do it.
Analyse the errors that still generate tickets, before going back to customisation. The remaining ticket share tells us which error categories the diagnosis doesn't explain well enough yet.