Leading from
the middle.
The part that usually goes uncredited, and the part that decides whether the design survives being built.
I was co-lead on the design and sole lead on production, the design-to-development pipeline that turns comps into shipped software across 3 surfaces and 2 parallel sprint tracks. This is the machinery. The scope engineering built from, the redlines that answered edge cases before they became guesswork, and the day-to-day of directing the build.
Co-lead on design. Sole lead on production.
I sat where the work actually converged. That middle position is unglamorous and decisive, it’s where a beautiful design either survives contact with engineering or quietly degrades. I call it leading from the middle: owning the machinery that turns designs into a shipped product.
Shaping the role-aware experience across all three surfaces. See the design work →
Specs, annotated wireframes, redlines, interaction docs, acceptance criteria, across parallel sprint tracks. The subject of this page.
The design-to-development pipeline.
What kept fidelity intact across 3 surfaces and a lot of hands was the production layer. The approved scope, the redlines, the edge-case docs, and the cadences between design and engineering. Made concrete, it looked like this.
What I owned end to end (specs & acceptance criteria, redlines, edge-case docs) run across two parallel tracks (the live system and net-new features) alongside the PMs.
The approved, prioritized user-story scope, role by role, priced MUST / HIGHLY DESIRED / NICE TO HAVE. 86 FCG stories across 16 functional areas. Scope arguments happened on paper, before code. (A real story: FCG29, two-level dashboard permissions, with its appliance-vs-web edge case written down.)
Designer redlines on the Create-Patient flow, the “DP comments” that turned a wireframe into something engineering could build without guessing: inline validation, required fields, and the duplicate-patient edge case.
The producer half, made concrete: align before code hardens, spec it, embed through the build to unblock, and hold the line in review, the loop that kept what shipped faithful to what was designed.
So what actually stopped the drift?
3 surfaces, 2 parallel sprint tracks, and a lot of hands is exactly the condition under which a polished design turns to mush by the time it ships. A process stopped the drift, and staffing that process was my job. Co-located on site, so questions got answered in minutes instead of sprints, and artifacts genuinely kept current. Fidelity scales on someone owning the connective tissue.
Connect 2.X shipped across 3 surfaces. The pipeline is why it shipped faithfully.
Connect 2.X launched on schedule and under budget, replacing fragmented systems with a unified, role-aware experience, and left behind durable inter-team cadences between design and engineering. I co-led the design, and I owned every artifact between that design and the build, and the thing that shipped is the thing we drew.
The design this pipeline shipped, wireframe to hi-fi, screen by screen:
The design work