Lead design work sits upstream of components: deciding which patterns earn a place, arbitrating when two teams want the same surface to behave differently, and writing the design-to-engineering contract so work ships without ambiguity. These five threads show where I set the convention, each now shaping how adjacent teams build.
Every creation flow had drifted into its own layout: split-screen workbenches, centered single-column cards, floating card grids. New surfaces had nothing to build against, so the product felt like several products stitched together.
I established the split-screen workbench as the standard: scrollable form on one side, sticky live preview on the other, responsive breakpoints instead of a rigid ratio. A variant switcher pinned atop the preview, a summary tab replacing the old review page, and inline error indicators on any tab with validation issues turned the layout into a system. Bringing the outlier flows into line made the convention hold platform-wide, so adjacent teams now build against it instead of reinventing it.
Teams relitigated the same question on every flow: stepper or tabs? With no shared rule, a flow that supported saving partway through would still force users down a rigid linear path because that's what the last flow used.
I authored the rubric the team now builds to: steppers for strictly linear flows where steps must be completed in order, tabs for non-linear, save-as-draft flows where users move between sections freely. Usage data grounded it; one flow forced every user through a multi-step stepper even though sixty percent created just a single item. Applying it where steppers fought save-as-draft behavior fixed the misfits, and adjacent teams carried it forward as their default reasoning, so the debate never has to happen again.
A core flow was blocked on one architecture question: were two related concepts the same thing, and how should orphaned items, creation scope, and naming behave depending on the answer? The disagreement sat buried in a long chat thread, and nobody could ship until it was settled.
I planned and facilitated a working session with the full cross-functional team. Assumptions mapping surfaced where people silently disagreed; a decision-tree exercise then traced each path's consequences without forcing a premature vote. Open unknowns went into the tree rather than being papered over, and the agreements, live disagreements, and next steps were documented with named owners, which unblocked the flow and left a record the team could reuse for the next contested call.
Design decisions lived in scattered chat threads and verbal agreements, so engineering tickets carried ambiguity and rework. The same questions resurfaced at handoff because no single reference defined what a surface should be.
I made the design file the source of truth, with tickets anchored to it and the reasoning behind each decision documented alongside the work. The bar for a good ticket: specific affected-area paths, explicit expected behavior, a design reference. Engineering could build without coming back to ask, and the contract gave the team a reusable definition of done.
Design, research, and content kept entering after scope was set. Engineering kicked off with open questions, mid-build cuts had no path upstream, and the same handoff failures repeated. Everyone felt it; nobody had named it.
I audited the handoff against real projects, from meeting transcripts to tickets to shipped work, and named five recurring failure patterns. The audit made the case for lifecycle checkpoints: discover, plan, and build gates with explicit entry criteria and named owners, so engineering starts from documented design and research instead of assumptions. A gate only catches what a team brings to it, so “Designin’ With Dani” came next: a biweekly design × engineering sync where in-flight work is reviewed while it’s still shapeable, with deep dives when a decision needs the full room.