For most of my career I’ve been the designer who also builds. That sounds like it would make engineering collaboration easy. Mostly it makes me aware of how much gets lost between the person who decided and the person who builds.
These days I define the problem, make the design calls and build the prototype. Then engineers I don’t manage build the real thing, often in another time zone, reviewed by senior engineers with their own standards. I don’t control delivery. What I control is what I hand over. So I put my effort there.
Start with the person on the other side
The developer who picks up my work wasn’t in the planning meeting. They have the card, the prototype and whatever I wrote down. If the card leaves a question, they either stop and ask, which costs a day across time zones, or they guess.
So before anything goes over, I read it as that person would. I now have a checker that does exactly this: it gets only the cards and the code they point to, nothing from planning, and lists every question the developer would have to stop and ask. Each question it finds is a day I don’t lose later.
The handoff has a shape
A handoff that travels has the same five parts every time:
| Part | What it answers |
|---|---|
| The short version | what this is and why, in three lines |
| The structure | which pieces exist, and where each behavior lives |
| The build order | what to build first, so each step can be checked before the next |
| The contract | what each side passes the other, and what “correct” means |
| The gotchas | the places I already got wrong, so nobody gets them wrong twice |
The last row is the one people skip and the one engineers thank me for. I’ve usually found the traps while building the prototype. Writing them down costs ten minutes.
Every acceptance criterion says how it could fail
“The layout adapts to the screen” can’t be checked. So every criterion I write comes with the observation that would prove it false: at this width, with this content, this element must not wrap. If I can’t say what failure looks like, the criterion isn’t finished.
That one habit changes the conversation with QA and engineering. We stop debating whether something “works” and check the case we agreed on.
Take the engineer’s design seriously, including against my own
Sometimes the engineer has a different design for the same problem. When that happens, I write a side-by-side comparison, and it always has four parts:
The last part is the one that matters. Checking someone else’s design closely is the best review my own work ever gets. The last time I did this, I found defects in my own material, and a claim I’d made but never measured. Putting that in the document, in writing, changes the tone of everything else. It’s not a pitch for my version. It’s two people trying to get it right.
Know who will review it, before they do
Senior engineers review my work, and each of them has standards: things they always block, things they let slide. I studied their past review comments until I could write those standards down, one profile per reviewer. Now my changes get checked against those standards before the reviewer ever sees them.
It isn’t about getting past reviewers. It’s about not spending their time on things they’ve already told everyone, in writing, many times. Their attention should go to the parts that need judgment.
Prove the build matches, then say what didn’t
When the build comes back, “looks close” isn’t the check. I compare the build against the prototype, value by value, and report what differs. Sometimes the difference is a defect. Sometimes the build is right and my prototype was wrong. Either way, it’s a list of specifics, not an impression.
When I chase a problem and rule things out, those go in the record too. A list of the explanations that turned out false saves the next person from testing them again.
Lead without the title
None of these engineers report to me. With the ones I work alongside every day, the move is agency rather than direction: show the problem and the evidence, ask what they’d do, and decide together. The structure above is what makes that work. Nobody has to trust my seniority. They can read the decision, the reason, the contract and the test.
That’s the collaboration I want to keep doing: design that arrives ready to build, with the reasoning attached, and engineers whose time goes to the hard parts.
Thanks for the read.