Eliminate friction in design-to-development handoffs to reduce rework and accelerate feature delivery
OKR Key Results
Reduce design revision requests after handoff by 50% (from 8 avg to 4 per feature)
Decrease time from design approval to dev start from 5 days to 2 days
Achieve 90% designer/developer satisfaction score on handoff clarity (currently 62%)
Implement standardized handoff checklist used in 100% of feature work
Team Goal
Yes - this is a team goal
Issues to Discuss
Design specs often lack edge cases and error states. Developers discover gaps mid-sprint and have to context-switch back to designers.
Figma comments get lost. No single source of truth for “ready for dev” status.
As with one of the other OKRs I reviewed recently I like this objective because it speaks to improving the team doing the work and improving their capacity.
That said, I’d like to see a “So that” on this objective - not standard I know but they can be helpful.
I’d like to make it clear why this is being done and what the expected benefit it.
I imagine that the team doing this work know perfectly well what achieving this would mean but I would like to see it spelt out to those outside the team.
The key results all pass the sniff test: numbers in all of them.
KR #1 looks reasonable “Reduce design revision requests after handoff by 50%”
However I worry a little bit. One way of reducing requests is simply for people to stop asking. It is going to depend on the culture of the organization.
If this OKR was given to a team, or set by someone without consulting the team, then in “weak” culture, people might simply stop asking.
So I’d like to see some indication of what the team expects here “Reduce design revision requests after handoff by 50% by implementing a standard checklist”
Which jumps us ahead to KR #4, “Implement standardized handoff checklist used in 100% of feature work”
Does this mean “Implement standardized handoff checklist” AND “use it for 100% of feature work” or does it mean “The list that is always used needs to be standardized” ?
KR#2 and #3 both take me back to the org culture.
In a supportive “psychologically safe” culture I can see these being effective. However, I worry that without these people will find ways of meeting these results but things might get worse.
OKRs don’t exist in a vaccuum and its hard to tell how to interpret these. Managed well they could be very positive, managed badly it could be “one step forward and two back.”