Good design dies in handoff. I found out why — and changed it.
Designers blamed implementation. Developers blamed the specs. I wanted to understand where the handoff actually broke down — from the developer's side — and what good looked like at scale.
Engineering partnership doesn't start with components. It starts with understanding where intent gets lost. This research found exactly that — and changed it at scale across the entire organisation.
The story
The research
This wasn't part of my role. I was working full-time as a product designer when I noticed the same friction recurring — design intent getting lost somewhere between Figma and the final build. I wanted to understand it properly before proposing anything.
I surveyed developers across IBM Software to find out where implementation actually broke down. The same issues surfaced repeatedly: missing error states, unclear component usage, designs misaligned to the Carbon Design System, and solutions that ignored technical constraints.
The finding
The technical gaps were fixable. The bigger finding was cultural — teams with the strongest outcomes weren't handing work over, they were working through it together. The teams who struggled weren't asking for better specs. They were asking to be involved sooner.
A word isn't just a word when it's encoding a process. Handoff tells designers their job is done. The issue wasn't that developers needed more from design — it was that both sides needed a different relationship to the work, built on collaboration and shared ownership from the start.
“Rename the whole process of ‘handover’ to something else. There are many designers still stuck in a waterfall mentality where handover signals that their work is final… This type of thinking impedes collaboration between design and development and prevents quick iterative improvement.”
Survey respondentDeveloper, IBM
What changed
Research without action is just interesting. I sequenced three interventions deliberately: test with developers, bring the conversation to designers, then translate it into guidance the whole organisation could use.
The FED session and Spark talk I delivered myself. The published guidance was a team effort — I led a small group, bringing together others already working on related problems, to turn the research into something repeatable and adopted at scale.
Lessons
Across 100 developers in 12 countries, the same pattern emerged: most quality issues weren't caused by people. They were caused by gaps in process, communication, and shared understanding.
Delivery isn't where design ends — it's where intent is most at risk of being lost. A design system can only close that gap if the people using it on both sides understand what it's actually for.
Developers aren’t the problem—the process is
Quality issues are usually caused by incomplete information, not a lack of care.
Words encode processes
Terms like handoff shape expectations, ownership, and behaviour.
A design system must cover the full picture
Error states, edge cases, and constraints aren't afterthoughts — they're where the system proves its value.
Continuous collaboration beats perfect handoff
The strongest outcomes came from ongoing conversations, not polished documentation.