I asked developers what was broken. Then I fixed 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.
Carbon Next has to be engineer-consumable. That requires understanding where implementation breaks down in practice, not in theory. This research is that knowledge — sourced directly from 100 developers across 12 countries.
The story
The research
Every team had its own approach to handoff, with no shared understanding of what good looked like. I surveyed developers across IBM Software to understand the problem at scale — asking what made implementation harder than it needed to be.
The same issues surfaced repeatedly: missing error states, unclear component usage, designs misaligned to Carbon, and solutions that ignored technical constraints. The goal wasn't to collect complaints — it was to identify where design intent got lost, and use that to scale better practice across IBM Software.
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. The findings became three things: a FED Hursley branch session, a Spark Design Festival talk, and practical design delivery guidance — each aimed at making better collaboration repeatable.
The FED session tested the findings with developers. The Spark talk brought the conversation to designers across IBM. The guidance translated the research into practical ways of working for teams.
Lessons
This research changed how I think about delivery. 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.
The role description states that "taste must be spoken, not only shown — or the intent dies in the handoff." This research taught me exactly why that's true. Delivery isn't where design ends — it's where intent is most at risk of being lost.
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.
The happy path is not a spec
Error states, edge cases, and constraints need the same attention as ideal scenarios.
Continuous collaboration beats perfect handoff
The strongest outcomes came from ongoing conversations, not polished documentation.