I found that as-is had a structural problem. So I ran a systematic evaluation across every step of the creation flow - annotating each screen by issue type and severity, cross-referenced against EAP session feedback. And presented the findings to engineering leadership. This was a set of 3 working sessions i hosted, with UX researcher, a content designer and UX engineer. 


Then I got engineering leadership aligned. That alignment wasn't incidental, By categorizing every issue with a severity rating, a specific recommendation, and an explicit note on implementation complexity, I had removed the ambiguity that usually kills these conversations. Nobody had to guess what the work would cost or argue about priority. The evidence made the case.

In as-is, the wizard had been built with a functional intent but had no experiential layer! Fields appeared without hierarchy. Required and optional inputs were treated identically. Instructions that should have been two sentences were paragraphs. The "Enable GenAI" toggle had no description of what enabling it would actually do.

I redesigned the full creation flow with the focus on sequencing steps to match with how practitioners actually think, not how the system processes input.

The most structural change was moving the payload step after attribute mapping. In the original flow, users were asked to define their request and response payload before they'd mapped a single attribute - the step was appearing before the reasoning that would inform it. Moving it after mapping and reframing it as a review rather than a definition task resolved the sequencing confusion without a single backend change.

The system already had the data. The order was the only thing wrong.

EAP participants filed it plainly: getting to the code to fix a single function required walking back through every preceding wizard step.

A thirty-second debug task had become a multi-step ceremony. There were 12+ customer-support tickets just around that!

The wizard worked for first-time creation. It was the wrong model for everything after it. I pushed to change the metaphor: creation stays linear and guided. But once an adapter is saved for the first time, it becomes a navigable document - six chapter, jump to any of them directly.

This reframe became the organizing principle for the entire feature. Error attribution in the validation report pointed to different chapters. The VSCode extension opened to specific chapter in context. In Phase 2, GenAI generation surfaces proposals chapter by chapter rather than as one opaque blob. One structural decision, cascading across every surface.