Bridging the gap between design and development

DfE Department for Education · via Version 1 · Nov 2024 - Dec 2024

Running a ways-of-working session with developers that changed how design work gets structured, demoed, and trusted.

  • DfE
  • Design-dev collaboration
  • Ways of working

The problem

There was friction between the design and development teams - not conflict exactly, but a disconnect. Handovers weren't landing as well as they should. Developers were receiving design work without enough context to break it down efficiently, and designers weren't fully understanding the constraints and thought processes developers were working within. The result was misalignment, slower delivery, and a gap in trust between the two disciplines that nobody had formally acknowledged or tried to fix.

Illustration of a design team collaborating around a wireframe mockup
Image from UX Republic

What I did about the problem

I took the initiative to do something about it - not by raising it as a problem in a meeting, but by getting curious. I set up a ways of working session with the developers to understand their world: how they approach a piece of work, what happens in their brain when they see a design demo, what they need to break work down into tickets and epics before refinement and estimation. I asked questions rather than made assumptions.

What I found changed how I worked. When developers see a design, the first thing they're doing is mentally breaking it into buildable chunks - they're thinking in tickets and epics before they've said a word. That's not a blocker, it's actually a discipline. Understanding that gave me a completely different lens for how I presented and structured design work.

Animated distinction between how designers and developers approach the same piece of work

What came out the other side

The ways of working session unlocked a shift in how I approached the whole design-to-development relationship. I started breaking down my own thinking to align with how developers would need to structure build work. I became more deliberate about the level of detail in tickets - even at early stages - because I understood why that detail mattered to them. I changed how I ran design demos, chunking up designs to mirror the ticket structure so developers and business analysts could follow the logic of what was being built and in what order.

The biggest outcome wasn't a process change - it was trust. When developers feel like a designer understands their world and is designing with them rather than at them, the relationship changes. The UCD and dev team became more collaborative, communication improved, and delivery felt less like a relay race and more like a team sport.

Thanks for all the UX direction - the admin area is very much yours. I thought that was really good for figuring out how we get all this flowing through from UCD to Dev.

Jeremy WilkinsTech Lead

What I learned

Friction between design and development is almost never about personality - it's about perspective. Developers and designers are looking at the same thing and seeing completely different problems. The moment you take the time to understand their angle, everything gets easier. I'd do this at the start of every project now.