What happens when you put the designer, PM, and developer together in real-time to fix bugs live — and why it became our standard practice.
Before every major launch, there's a window — usually tight — where the design and the coded reality are just slightly out of sync. Not enough for anyone to flag a blocker, but enough to erode the experience. Small visual inconsistencies. Layout rules that rendered differently than spec. Interaction moments that felt almost right but not quite.
We found a way to close that gap in one session instead of weeks of Jira back-and-forth. We call it a Live Coding Session (or Dev-Designer Pairing), and it's now one of the practices I'd advocate for on any cross-functional team.
The format is simple: the designer, PM, and developer sit together — or join the same screen share — and work directly in the test environment. We prepare a list of UI/UX issues beforehand, the developer addresses them live, and we validate the changes in real-time. It sounds obvious. It's surprisingly rare.
"The goal isn't to review. It's to decide, fix, and move — together, in the same moment."
The session that convinced me happened during the styling work for Help Articles in Geotab Support Center. We were applying custom CSS to content authored in Heretto (a structured content platform), which was causing unexpected rendering issues — visual bugs that were only discoverable in the real environment. The back-and-forth ticket approach would have taken days per bug. Instead, we resolved them in hours.
Watching code change in real-time while you're in the same conversation collapses ambiguity. When a developer says "that won't work because of how the component is structured," you can immediately redesign the approach — not two days later in a comment thread. The PM can weigh in on priorities on the spot. Decisions that would normally take three rounds of async feedback happen in minutes.
I came away from our first session with a much clearer understanding of developer pain points — what kinds of specs create confusion, what CSS constraints to anticipate, where the design-to-dev handoff was producing friction. That knowledge directly improved how I prepare future handoffs: better annotation, more explicit state documentation, fewer ambiguous edge cases.
This is the one that surprised me most. These sessions create a kind of personal working relationship that async tools just can't replicate. You see each other problem-solve in real-time. You hear the frustrations directly. You brainstorm together instead of leaving notes on a mockup. In a cross-functional environment where design is often pushing for innovation against implementation constraints, trust with your developers is not optional — it's the foundation everything else depends on.
That first session felt effortless in a way that most design-dev collaboration doesn't. We covered a bug list that would have taken a full sprint at normal velocity. The quality difference in the shipped product was noticeable. And critically — we decided to keep doing it. Live coding sessions are now a standard part of our process before any significant launch.
If you're not doing this already: try it once. Pick the next pre-launch crunch, get everyone in the same room (or on the same call), and watch what happens to your alignment speed.
Workshops are primarily activity-driven. Meetings are discussion-driven. Live coding sessions are something different: they're resolution-driven.
Further reading: On Pair Programming — Martin Fowler gives a great technical deep-dive into the pairing model this is built on.
I'm always up for a conversation about process, design-dev dynamics, and building better cross-functional teams.
Get in touch! →