Every creation flow on the platform had drifted into its own layout. Some used a split-screen workbench with a live preview, others used centered single-column cards, others floating card grids. New surfaces had nothing to build against, so each team reinvented the structure and the product felt like several products stitched together.

I established the split-screen workbench as the standard layout for creation flows: a scrollable form on one side, a sticky live preview on the other, with defined responsive breakpoints so it wasn't locked to a rigid ratio. I specified the shared conventions that made it a system rather than a screen, a variant switcher pinned to the top of the preview and present across every tab, a summary tab replacing the old separate review page, and inline error indicators on any tab with validation issues. Then I brought the outlier flows into line so the convention held across the whole platform rather than living in one team's corner.

Teams kept relitigating the same question on every flow: stepper or tabs? Without a shared rule, the choice was made case by case, inconsistently, and a flow that supported saving partway through would still force users down a rigid linear path because that's what the last flow happened to use.

I authored the decision rubric the team now builds to: steppers are reserved for strictly linear flows where steps must be completed in order; tabs are the pattern for non-linear, save-as-draft flows where users can move between sections freely. I grounded it in usage data, one flow forced every user through a multi-step stepper even though sixty percent created just a single item, so the linear pattern was actively working against them. I applied the rubric to the flows that needed it most, replacing steppers that fought save-as-draft behavior, and it carried forward as the default reasoning for adjacent teams.

A core flow was blocked on an unresolved architecture question: were two related concepts in the system actually the same thing, and how should orphaned items, creation scope, and naming behave depending on the answer? The disagreement was buried in a long chat thread, and nobody could ship until it was settled.

I planned and facilitated a working session to resolve it with the whole cross-functional team. I ran an assumptions-mapping exercise first to surface where people silently disagreed, then a decision-tree exercise to trace the consequences of each path without forcing a premature vote. I moved the open unknowns directly into the decision tree as the transition between activities, then documented the agreements, the live disagreements, and the next steps with named owners.

Design decisions lived in scattered chat threads and verbal agreements, so engineering tickets carried ambiguity and rework. The same questions resurfaced at handoff because there was no single authoritative reference for what a surface was supposed to be.

I drove the standard that the design file is the source of truth, with tickets anchored to it and the reasoning behind each decision documented alongside the work. I set the bar for what a good ticket looks like, with specific affected-area paths, explicit expected behavior, and a design reference, so engineering could build without coming back to ask. The contract reduced ambiguity at handoff and gave the team a reusable definition of done.