Rey MungaiProduct designer
← My Work

Building the OS behind the design team

KOKO Networks · Senior Product Designer · Clean cooking · 2025

Building the handbook, QA process, growth framework and offboarding system that let the four designers I managed hold one bar for quality across four product squads, instead of everyone quietly doing it their own way.

A group of people stand talking in a sunlit courtyard beside a table with papers and a laptop.
~30%less design-to-dev rework
4designers managed, one bar
4product squads
6dimensions, one shared scale

The situation

I managed four designers, spread across Platform and CX, and reported to the Principal Designer. The inconsistency in what shipped had nothing to do with individual skill. Design maturity was undefined, so there was no shared answer to what “good” meant beyond “does it look right.” QA happened differently squad to squad, so rework landed on engineering after the fact. New designers ramped up however their buddy happened to onboard them that week. And when someone left, unwritten context, half-finished decisions and file ownership mostly left with them.

What I built

I drafted the team’s operating system as one connected structure rather than separate documents: a handbook, a QA process, a growth framework, an onboarding path and a handover process, all built off the same model of what design maturity means at KOKO.

One model: six dimensions, every level evaluated the same way
ImpactDesign ThinkingExecutionCollaborationGrowthLeadership
Five phases, each with a defined output
DiscoverDefineDesignDeliverMeasure
Role ladder
Design Intern…Principal Designer
The shared model inside the DesignOps Handbook.

The DesignOps Handbook set the shared definition: design maturity measured by how embedded design was in product and business decisions, not by headcount or visual polish, and a role ladder from Design Intern through Principal Designer, with every level evaluated against the same six dimensions. It also fixed the design process into five phases, each with a defined output, so a squad’s progress could be read at a glance.

The Design QA Report Template made that standard checkable: visual consistency, interaction patterns, accessibility and technical feasibility, tied to a specific Jira ticket and Figma file, and reviewed before a feature shipped rather than after engineering had built against it.

Two pages from the system: The Design Onboarding Quest, and the Design Team Operating Handbook with its sections on design maturity and the role ladder.

Two more templates from the system: the Designer Growth Plan Template and the Designer Handover Template.

The Designer Growth Template ran on the same six dimensions, so a development plan, a monthly readiness scorecard and a promotion conversation all read off one scale. The Onboarding Quest turned the first month into a structured, gamified path, from Initiate to Guild Member, with the handbook as required reading in week two. And the Designer Handover Template made departure a structured handoff: ownership of every product and asset, a live inventory of what was active, parked or fragile, the reasoning behind past decisions, known risks, and a 30/60/90 plan for whoever picked the work up next.

All five pieces were mine to draft, and they went live between 2024 and 2025 after sign-off from KOKO’s Principal Designer, the role the handbook names as owning cross-squad design strategy.

The toolkit is shared publicly: Design Leadership Toolkit.

When it was actually used

A new designer went through the full quest end to end rather than the ad hoc shadowing that came before it, graduating by week four into full sprint work instead of being eased in informally.

The clearer evidence is a handover I received from a designer on my team who left in January 2026. It isn’t a tidy example, and that’s what makes it useful. A repair data tool was functionally complete but fragile because design QA hadn’t been run on it. A promotions engine was paused, waiting on a full requirements list from marketing. For at least one system, nobody could immediately say who owned the file.

Repair data toolFunctionally complete, but fragile: design QA hadn't been run on it yet.Named owner and priority for the QA
Promotions enginePaused mid-flight, waiting on a full requirements list from marketing.Clear condition for resuming
Asset ownershipSplit across several people; for one system, nobody could say who owned the file.Made visible and assigned
What the January 2026 handover surfaced, and what it did about each thread.

The template didn’t make her workload tidy, but it made every open thread visible and assigned to someone. Her own final advice to the team, protect open communication, don’t let PMs and engineering lead design decisions by default, invest in workshops over solo discovery, became part of what the next person inherited rather than something that left when she did.

Results

Design QA and the documentation standards around it cut design-to-development rework by roughly 30% across the four product squads, and it’s still the standard those squads work to. A real onboarding and a real departure both ran through the system without losing what the designer knew. Growth conversations, onboarding and offboarding stopped depending on whichever manager or buddy a designer happened to get, and started running off one shared model, signed off at the top of the design org.