All case studies →
Product process & collaboration
Designing the process behind the product
Improving design-to-engineering handoff by treating the collaboration itself as a design problem.
Role
Senior Product Designer
Period
2026
Duration
4 months
Team
Designers and engineers across products
The challenge
Expert users were working through long analytical journeys with a lot of information to hold in mind. I focused on making those journeys easier to follow without oversimplifying the underlying work.
My role
I co-led the initiative from research through synthesis, facilitating workshops and working with Product and Engineering to turn the findings into practical actions.
What I focused on
- Cross-functional research
- Workshop facilitation
- Process design
- Engineering collaboration
Design principle
This work shaped how I approach complex B2B products today: simplify the path through the problem, not the expertise behind it.
01
When handoff became a design problem
The first signal came from an engineering retrospective. On the surface, the issues looked like handoff problems. But the more I looked at them, the less they felt like isolated mistakes.
What stood out was the gap between disciplines. Product decisions were moving into implementation without always carrying the right context with them. Some technical perspectives were only entering the conversation once the solution was already taking shape.
Product context
Context can get lost
Technical perspective arrives late
Ownership becomes unclear
Design intent
Technical context
Implementation
A conceptual view of where context can break down across a handoff.
Another Product Designer and I co-led the initiative from start to finish. We shaped the research questions, created the surveys, planned and facilitated the workshops, synthesised the findings, proposed actions, prioritised them, and shared the recommendations back with Product and Engineering.
01
Following the problem, not the original plan
We started with front-end engineers, where the friction looked closest to the traditional design handoff.
That would have been a neat and tidy process if the problem had stayed there.
It didn’t.
1
Retrospective signal
Design-related friction surfaces.
2
Front-end survey
Understand the current experience.
3
Front-end Workshop
Clarify ambiguity and explore solutions.
4
Back-end survey
Explore a different set of needs.
5
Back-end Workshops
Discuss and co-create with Engineering and Product.
6
Synthesis + validation
Combine themes, actions and ownership.
We were only seeing half the problem
That shift changed the initiative. It stopped being just about design handoff and became a broader look at how Product, Design and Engineering worked together around implementation.
03
More detail was not the answer
Going in, I expected developers to want more detail. What came back was different. They wanted earlier involvement.
They wanted earlier involvement.
What kind of context do they need, and when do they need it?what kind of context do they need, and when do they need it?
The problem was less about documentation volume and more about timing and collaboration.
1
Initial assumption
“More detail”
Clearer specs and documentation.
2
What research showed
Front-end
Interaction intent
States and behaviours
Specifications
Current design
Design-system context
Useful context appears closer to implementation
Back-end
Business logic
Technical constraints
Dependencies
Long-term context
Technical implications
Useful context needs to arrive earlier
Different context, at different moments
That changed the direction of the work. Better documentation could help during implementation, but it could not recover the opportunity to influence a decision that had already been made.
04
Designing the response with engineers
That changed the direction of the work. Better documentation could help during implementation, but it could not recover the opportunity to influence a decision that had already been made.
1
Weekly committee
A regular space for shared decisions and continuity.
2
Slack support
Questions and implementation issues stay visible.
3
Product syncs
Product needs shape the system’s next priorities.
4
Roadmap
Shared priorities become a sustainable direction.
Key findings that changed the direction.
More recurring meetings
Too much default overhead.
More developer documentation
Solved one problem by creating another.
One rigid process
Different work needed different involvement.
Forcing new habits
Strengthen behaviours that already work.
After the workshops, another Product Designer and I used AI to accelerate the first pass of synthesis, then reviewed the outputs ourselves and turned them into a structured set of actions.
Survey responses
Workshop notes
Transcripts
AI-assisted synthesis
cluster and summarise
Human review
interpret, reconcile, challenge
Theme
Earlier involvement
Shared context
Decision clarity
Knowledge sharing
Status
Active
Ready to try
Needs discussion
Active
Owner
Design
Product
Engineering
Shared
Cross-functional validation
feasibility, gaps, ownership
AI helped compress the material.
The judgement stayed with us.
We then walked through that work with the Head of Engineering to test whether it felt realistic, where the ownership should sit, and whether anything important was missing.
01
What changed
I left before the whole initiative could fully play out, so I would not frame this as a finished transformation.
What did change was the shape of the collaboration. Engineers had helped diagnose the problem and shape the response.
One useful outcome was a series of technical architecture walkthroughs that helped Design build a stronger mental model of how the product worked.
Shared product understanding
Design shares intent
Engineering shares technical context
Design builds a stronger system mental model
Better questions happen earlier
The goal was understanding, not shifting engineering ownership to Design.
The initiative led to technical architecture walkthroughs for Design.
Handoff starts earlier than I used to think
Technical input is most valuable while decisions can still change.
A process only helps if it reduces effort overall
If it adds work without reducing uncertainty, it is probably the wrong solution.
Engineers are part of the design learning loop
Some of the strongest ideas came from the people building the product.
The goal was never for designers to make technical decisions. It was to understand enough context to ask better questions earlier.
This project changed how I think about handoff.
I stopped seeing it as the moment when Design passes work to Engineering, and started seeing it as a longer collaboration where better outcomes often depend on the right context showing up sooner.
Next case study
Designing the process behind the product
Read on →
