Bridging the gap between design and development
Running a ways-of-working session with developers that changed how design work gets structured, demoed, and trusted.
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.

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.

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.”
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.