Two-week sprints don't leave much white space. By Wednesday of any given week, my calendar was usually a wall of back-to-back review and refinement meetings, the kind that get scheduled next to each other simply because there's nowhere else to put them. I'd come out of two of them stacked together and need a minute just to remember what I'd been working on before they started.
As a junior UX researcher, my job description didn't technically include sitting in those rooms. UI design wasn't my lane. For a long stretch, I went anyway, and said almost nothing. It would have been easy to read that as wasted time — a researcher, quietly present, contributing nothing visible to a conversation about implementation details. I didn't see it that way, even then, though I couldn't have explained exactly why.
Designers default to the happy path. It's the version of the flow where everything goes right — the field is filled in correctly, the network holds, the user does the thing you designed for. Developers live somewhere else. They're the ones who have to account for what happens when the input is malformed, the request times out, or the user does something you never anticipated. In review and refinement, that gap between the two perspectives is exactly where the useful conversation happens.
I remember one dialog in particular: adding support for alternate addresses inside the Edit Profile flow. The original version was clean — a single address field, no branching, no edge cases to speak of. The moment we introduced the option to add more than one address, the shape of the problem changed. Which one is primary? What happens if someone deletes the address currently in use elsewhere? What does the form do with a second address that's left half-filled? None of that showed up in the first version of the design — it surfaced because a developer, reading the same screen I'd just presented, asked what the interface was supposed to do when the assumption of "one address" broke.
There's a useful frame from UX writing on this: errors aren't one thing. Some are slips, where the user's intention was right but the execution faltered — a mistyped email, a wrong tap. Others are mistakes, where the user's mental model of the system was wrong from the start, and no amount of forgiving interaction design fixes that on its own — it needs clearer labeling and better alignment with what the user expected. I didn't have that vocabulary as a junior researcher. What I had was a room full of developers who'd catch the distinction instinctively, because they were the ones who had to build the recovery path either way.
That's where the "handoff or handshake" question started to matter to me. A handoff, as it's usually practiced, is a one-way transfer — a set of screens goes over the wall, and whatever wasn't specified becomes someone else's problem to interpret. A handshake is different. It's mutual: both people acknowledging, before parting ways, that they've actually agreed on what's being built — including the parts that aren't pretty. I started treating review meetings as the handshake, the moment where a design stopped being mine alone and became something we'd both stress-tested.
There's a quieter thread underneath all of this, too. Nobody was tracking whether I spoke up in those meetings, or whether I came prepared, or whether I actually listened when a developer flagged something inconvenient late in a sprint. Showing up consistently, and taking that feedback seriously even when no one would have noticed if I hadn't, turned out to be its own kind of practice — the sort of unglamorous consistency that trust with a team is actually built on.
As a junior UX researcher, I spent a lot of time in rooms where I technically had nothing to deliver. I went anyway, because I learned more from the developers explaining unhappy paths than from almost anything I read on my own. Over about two years, that habit — showing up, listening past my own role description, treating the handoff as something to be agreed on rather than dropped off — is a large part of what moved me from UX Designer into Product Designer.
None of that came from a framework. It came from choosing, sprint after sprint, to treat the relationship with engineering as something worth protecting — a handshake, not a handoff.