When to workshop with Dev

Ideally, UX introduces development to pieces of a flow while it’s actively being built. This gives the team a chance to surface insights, obstacles, and requirements as design shapes the individual capabilities. It’s much easier in a smaller, pod-style team where UX is embedded in daily agile ceremonies. For larger, shared-service style teams, it can feel less appetizing. The truth is that the time it takes to workshop is going to happen no matter what.

Questions will need answers. Decisions will need to be made. If that process doesn’t happen before grooming, then developers soak up that time during grooming/refinement. Worst-case scenario? It doesn’t get caught — at all — until after a card is picked up and then development has to make it work on the fly.

When UX claims to reduce rework, this is exactly what we mean. If UX and product fully flesh out ideas in isolation, break them into Jira cards, and then drop a huge chunk of work into the backlog, the team ends up workshopping in refinement.

Devs are left trying to wrap their heads around the concept on the spot, without the big picture or enough digestion time to give useful feedback. That’s when UX has to circle back and crank out updates, annotations, or revised artifacts. Dev may need to spike on an element of the design. As a result the anticipated estimated completion date gets pushed back, because technically the design wasn't ready.

Let’s be honest: what you have at this stage are first ideas. As I like to say,

“First ideas are worst ideas.”

The point of failing fast in UX is to fail in workshop, not in production. Every Figma should start out as a "scarecrow" — rough, unpolished, ready to be torn apart and rebuilt until it actually performs the job well.

If workshopping happens too late in the agile cycle, design can look like it’s floundering. Cards don’t appear “ready,” functionality shifts last-minute, and the team feels like design is changing on the fly. The real issue isn’t poor design—it’s poor timing.

What Works Best

I’ve seen the most success when there’s a designated time for UX to bring work-in-progress to the team. It doesn’t have to be every week (UX doesn’t always have shiny new features to present if we’re deep in research). When it happens, it should be a space for rough, annotated mocks, messy Figma boards, or even a scrappy Miro map.

• For big flows, story maps work wonders. Breaking down large journeys with the dev team helps everyone see the chunks of work in context.

• For smaller efforts, sometimes all it takes is a one-on-one with a developer. One of my favorite moments was during a massive portal redesign — a developer literally drew red boxes around failure points to show where error messaging would break. That one exercise saved hours of back-and-forth later.

Speaking of error messaging: don’t forget the unhappy paths. A seasoned UX can guess where things might break, yet developers usually see even more edge cases than we do. Workshop those paths early.

The Bottom Line

UX should be workshopping with development while design is still forming. If that’s not possible in a larger, shared-resource setup, then carve out a recurring time for rough, unpolished presentations. The goal is simple: by the time refinement rolls around, dev spikes are complete, error paths are accounted for, and no cards are bouncing back to UX for updates and no new spikes are needed to answer questions.

You can feel the difference in a team's energy when they have enough familiarity to build expectation around what they know is coming down the pike. If it feels like your team is always being pivoted, try inviting design to workshop unfinished work and have dev break the work into stories.