LEADERSHIP · DESIGN OPERATIONS
Design Operations
Less multitasking. Faster design-to-development handoff.
I reorganised the design team’s workflow by limiting parallel tasks, introducing regular Design Review and improving handoff to developers.
Design lead · Workflow · Allocation · Review · Design QA
Planning and sequencing with PM + development lead
−42%
Time in Review
4.12 → 2.38 working days · includes queue and waiting
−27%
System Cycle Time
≈6.88 → 5.0 working days · external priority pauses excluded
OPERATING DECISION
A clearer design workflow
I defined the stages from task intake to development handoff, formalised Design Review and set criteria for when designs were ready for development.
WIP = 2 tasks / designer
Too much work in progress. Not enough finished.
Designers were juggling around five tasks at once, with unfinished work and long queues. I reworked the flow to help the team finish work before starting more.
BEFORE · OBSERVED PATTERN
~5
Concurrent tasks per designer
AFTER · NEW POLICY
2
WIP limit per designer
More work in progress did not mean more work finished. Switching between tasks fragmented attention while unfinished work accumulated.
Want to feel how task switching affects your focus?
Try two short typing rounds and compare your times. It takes about a minute.
Sequential completed
Next: alternate letters and digits.
Your two rounds
- Sequential
- Switching
- Difference · switching − sequential
- Relative to Sequential
The work stayed the same. The order changed.
OPERATING MODEL
I redesigned the path from intake to handoff
WIP = 2
I introduced a limit of two tasks per designer to reduce competing unfinished work and context switching.
Review the work
I formalised regular Design Review around the largest queue, making review a normal part of delivery.
Make handoff explicit
I made Ready for Dev the design handoff and kept Design QA after development, so quality stayed in the delivery flow.
Planning around the flow
→↓
→↓
I created a standard brief for external clients and introduced regular reporting. The brief captures requirements before design begins, while reporting keeps task status and priorities visible.
I define and break down design tasks, allocate work, lead Design Review and oversee design quality. I agree priorities and plans with the PM and Dev Lead.
Less waiting. A shorter path to development.
After changing the workflow, I compared two large features: Files and Catalog. Catalog spent less time in Review and had a shorter overall cycle, even though direct design work took longer.
Files n=8 · Catalog n=9 tasks with verified status histories · working days
Days
Common scale
Time in Review
−42%
Files
4.12 d
Catalog
2.38 d
Direct design time
+30%
Files
1.88 d
Catalog
2.45 d
System Cycle Time
−27%
≈6.88 → 5.0 working days
Files 8 · Catalog 12 task ranges
Files · ≈6.88 d
Catalog · 5.0 d
External priority pauses excluded from Catalog intervals.
What changed
In the comparison, Time in Review was 42% shorter and the adjusted System Cycle Time was about 27% shorter. Review had previously involved substantial waiting, so I made it an explicit step and improved the handoff process.
| Calculation | Files | Catalog | Observed change | Samples |
|---|---|---|---|---|
| Time in Review | 4.12 d | 2.38 d | −42% | 8 / 9 status-history tasks |
| Direct design time | 1.88 d | 2.45 d | +30% | 8 / 9 status-history tasks |
| System Cycle Time · task ranges, external priority pauses excluded | ≈6.88 working days | 5.0 working days | −27% | 8 / 12 task ranges |
SUSTAINED PRACTICE
A delivery model the team kept using
The model became the team’s normal workflow, rather than a one-off process experiment.
I owned
Workflow, allocation, review and design quality
We shared
Planning and sequencing with PM and the dev lead
The team delivered
Design execution and engineering implementation
REFLECTION · HANDS-ON LEADERSHIP
