Section 2 — The situation
Product context
A UI release that caused friction in every direction
After a significant UI release, the post-mortem was uncomfortable. Engineers had questions about interactions that weren't documented. Designers were frustrated that components had been implemented differently to the spec. QA was catching regressions that had slipped through handoff. The same conversation was happening in three different rooms — without ever converging.
flows into
Section 3 — How it started
I noticed the pattern early. It wasn't a single incident — it was a systemic gap between what was designed and what engineers needed to build it. The handoff process existed, but it wasn't working. Files were being shared but not understood. Questions were being asked but too late in the process.
The decision
No ticket. No formal ask. Just a session.
I didn't write a process proposal or raise a ticket. I booked a recurring slot, gave it a name — the Figma Drop-in — and invited the engineering leads. The first session had three people. By the fourth it had ten. The idea spread because it solved a real problem, not because it was mandated.
Section 4 — What I created
The Figma Drop-in was a recurring weekly session — informal, practical, and open to anyone in engineering or design. The format was simple:
Component walkthroughs
Each session covered one or two upcoming components in detail — interaction states, edge cases, responsive behaviour. Engineers could see exactly what was expected before writing a line of code.
View-only Figma access
Every engineer was given view-only access to the Figma workspace. Not to review designs, but to have a reference point they could return to independently — reducing questions during development.
Open Q&A format
The second half of each session was open. Engineers could raise anything they were uncertain about — a spec that felt ambiguous, a token they didn't recognise, an interaction that seemed underspecified. Design answered in real time. The answers were recorded in Confluence for anyone who missed the session.
Section 5 — How it ran
The sessions settled into a consistent rhythm within a month. Design prepared a short agenda the day before — usually a Figma frame walkthrough and two or three open questions from the backlog. Engineers came prepared with their own questions.
What worked
The engineers started reviewing designs before builds
By the third sprint cycle, engineers were opening Figma before starting a component build — not after. They were flagging potential issues during the session rather than during QA. The loop had shortened significantly.
Section 6 — What changed
Outcome
Highlighted as a major factor in reduced release friction
In the next quarterly retrospective, the Figma Drop-in was highlighted by the engineering lead as one of the most impactful changes to the release process that year. Specifically: fewer last-minute spec questions, reduced QA regression rate on new components, and a measurably better relationship between design and engineering. None of this required a tool change, a process overhaul, or a budget.
"Process design is a design skill. The hardest part is making it feel like it was already there."
Section 7 — What I took from this
Reflection
The gap between design and engineering is a design problem
The most useful thing I learned from this project is that communication failures in cross-functional teams aren't personality problems or prioritisation problems — they're usually structural gaps. When designers and engineers don't understand each other's constraints, they make assumptions. When they share a space regularly, those assumptions get replaced by real information. The Figma Drop-in was a structural fix disguised as a calendar invite.