From handoff to shared ownership

We'd always had documents floating around defining what "good" looked like at handoff. But as things ramped up and deadlines tightened, even before the acquisition, the handoff got lighter and lighter. Under pressure, it's the first thing to thin out. Designs would go over the wall on the assumption that we were all pulling from the same design system, so surely not much needed saying. That assumption was wrong, and quality was dropping because of it.

My first attempt to fix it was a checklist. One shared standard every designer would run before handoff: use the tokens, check accessibility, all of it. It made sense on paper. It mostly didn't take.

Two reasons, and they turned out to be the same reason. First, I was pushing it onto twelve-plus designers without real buy-in. I got a couple of the design leads on side, but you can't add process to people's already-full plates by willpower alone, and people are reasonably wary of change. Second, and this is the one I missed at the time: the checklist was a design-to-engineering handoff tool built entirely without engineering in the room. A handover only works if the people receiving it helped shape what's useful to them.

Both failures were the same failure. I'd built a solution for people and at people, instead of with them. That lesson is the whole reason the next attempt worked.

The chance to do it properly came with the single app. We were consolidating three separate apps into one, which meant a smaller core team (just me and two other designers on the app itself), full ownership of the design system, and a single fresh codebase to work from.

It also came with timing I didn't want to waste. The app would eventually reopen to the other product teams (commerce, goals and challenges, recognition to follow), each with their own designers contributing. Far easier to establish a way of working while the team was small and then scale it out, than to retrofit one across a crowd. So the goal was to get the process right first, with the core team, before the doors opened.

I took what I'd learned and did the opposite of the checklist. Instead of handing engineering a finished process, I sat down with the engineers and the eng leads, walked through where I thought the current handoff was falling short, and proposed something we'd shape together. And I positioned it deliberately gently: not a permanent mandate, just a short trial, scoped to the core team only. Low threat, easy to say yes to.

The model itself was simple. It added two points of design collaboration to the build cycle where there had been none. Before we wrote any documentation or build tickets, we'd review the redesigned component or primitive set with the engineers, talking through naming, props, and how it would actually be built. And after build, we'd add a design-led QA pass, checking the visual and structural detail that standard engineering QA isn't really looking for. Two checkpoints, one before and one after, closing the gap at both ends.

The conversations got specific fast, and that's what made them real. How we'd name things. Which groupings were worth building and which weren't needed yet. Where a component should hold its padding (the parent), versus letting the base atom simply fill its space. Sometimes what design needed internally and what the codebase needed were different things, and the only way to find that out was to say it out loud, together, and keep Figma, Confluence, Storybook and the code telling the same story.

The mechanism mattered, but the real shift was in how people worked, and it crept up slowly before it took hold.

The first few sessions were quiet. It'd be the head of engineering and maybe one other engineer, and a lot of me asking a question and getting silence back. I'd wait it out, then joke: "don't all speak up at once." By the end, all four engineers were fully in it, bouncing ideas around, weighing naming and props, telling us when something didn't need building yet. The cameras came on. People who used to receive designs started to help shape them.

Underneath that was the thing I got most wrong going in, and most right by the end. What had looked like a turf problem was never really about territory. There was a quiet misconception on both sides: engineers felt design was throwing work over the wall at them, and design felt engineers went off and built whatever they wanted. Both were guessing, because nobody was actually talking. It wasn't a turf war. It was a communication vacuum, and each side was filling it with the least generous assumption about the other.

Once we started having the honest conversations, and once engineers could see there was real, actionable input they could make rather than just orders to follow, the defensiveness dropped. The walls came down, and people came out of their shells. It stopped feeling like work being passed from one person to the next, and started feeling like a team building something together.

The checklist wasn't a failure, it was the tuition. It taught me that process imposed on people doesn't stick, and that a handoff built without the people receiving it is only ever half a handoff. Everything that worked the second time was me applying that.

And the deeper lesson: most design-and-engineering friction isn't a disagreement, it's a silence. Give people a genuine reason to talk, make the input real rather than performative, and start small enough that saying yes is easy, and the collaboration tends to build itself. My job wasn't to enforce a process. It was to open the conversation and hold it open long enough for the walls to come down.