Building the OS Behind the Design Team
Building the handbook, QA process, growth framework and offboarding system that let a five-person design team hold one bar for quality across four product squads, instead of five people quietly doing it five different ways.
Role
Senior Product Designer
Industry
Clean Cooking
Year
2025
What I built
I drafted the team's operating system as one connected structure rather than four separate documents: a handbook, a QA process, a growth framework, and a handover process, all built off the same underlying model of what design maturity means at KOKO.
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 running from Design Intern through Principal Designer, with every level evaluated against the same six dimensions: Impact, Design Thinking, Execution, Collaboration, Growth, and Leadership. It also fixed the design process itself into five phases, Discover, Define, Design, Deliver, Measure, each with a defined output, so a squad's progress could be read at a glance instead of guessed at in standup.
The Design QA Report Template took that shared standard and made it checkable: visual consistency, interaction patterns, accessibility, and technical feasibility, tied to a specific Jira ticket and Figma file, reviewed before a feature shipped rather than after engineering had already built against it. This is the piece the rework figure on my CV comes from.
The Designer Growth Template ran on the same six dimensions as the handbook, so a designer's development plan and their manager's monthly readiness scorecard were reading off the same scale a promotion conversation would eventually use, not two vocabularies that needed reconciling at review time.
The Onboarding Quest turned the first month into a structured, gamified path, Initiate, Explorer, Collaborator, Contributor, Guild Member, with the DesignOps Handbook itself built in as required reading in week two, so new designers hit the same standard the rest of the team was already working to rather than whatever their buddy happened to pass on.
And the Designer Handover Template made departure a structured handoff instead of a quiet loss: 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 itself names as owning cross-squad design strategy. That sign-off mattered structurally as much as politically: the six-dimension model, the QA gate, and the offboarding process weren't just something I'd decided the team should follow, they were sanctioned as the standard by the most senior design authority in the org.
What happened when it was actually used
Two real instances back this up, one at each end of a designer's time on the team.
On the onboarding side, a new designer went through the full quest end to end rather than the ad hoc shadowing that came before it: orientation and tool access in week one, design system fluency and team rituals in weeks two and three, a self-led task and a shadowed QA review by week four, graduating into full sprint work and the design team's contributor rotation instead of being eased in informally over an undefined first month.
On the offboarding side, the clearest evidence is a handover I received directly, from a designer on my team who left in January 2026. It isn't a tidy example, and that's what makes it useful. Her active work wasn't uniformly finished: a repair data tool was functionally complete but flagged as fragile specifically because design QA hadn't been run on it yet, and shipping it unreviewed risked slowing down the field technicians who'd actually use it. A promotions engine had been paused mid-flight, waiting on a full requirements list from marketing. Asset ownership was split across several people, and for at least one system nobody could immediately say who owned the file. That's exactly the kind of mess a handover process exists to catch rather than prevent. The template didn't make her workload tidy, but it made every open thread visible and assigned to someone: a named successor and a stated priority on the unfinished IA work, a named owner and priority on the QA that still needed running, a clear condition for resuming the paused work instead of it quietly dying. 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 it sits inside cut design-to-development rework by roughly 30% across the four product squads it touched, and it's still the standard those squads work to. The system also held up at both ends of a designer's tenure, not just in the middle where it's easiest to design for: a real onboarding ran on it start to finish, and a real departure was handed off through it without losing what that 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, of what the function was accountable for holding.
Other projects
Designing the Cooker and Canister Swap Process for KOKO's Agents
Redesigning how KOKO Agents replace faulty cookers and canisters, from a paper process that needed a rep stationed in every shop, to a five-minute flow built to survive the ways real customers don't fit the happy path.
One Set of Frameworks, Two Diagnostic Products
Kauli and Matrix are two AI-native products I designed and built solo under Suluhu Studio, both using the Claude API. They look like separate tools, a decision diagnostic and an organizational maturity assessment, but they run on the same underlying frameworks pointed at two different targets: one decision at a time, or a whole design function at once.
Moving M-PESA Statement Verification Out of the Branch
A self-serve verification flow for 50M+ users, including a USSD path for feature phones, that removed tens of thousands of branch visits a day.
From 90 Interviews to Two Programs: Designing Bohoka
Design research and co-design work behind Tegura Ejo Heza, a mental health literacy and peer support program for young people in Rwanda, built from the ground up with the people it was for.