One system for KOKO's operations and products

Maridadi gave KOKO's product squads one standard to ship against and cut design-to-development rework by roughly 30%.

Role

Senior Product Designer

Industry

Clean Cooking

Year

2023 - 2026

Maridadi powers KOKO's products on both sides of the business. Inside, it runs the operations platform staff use across 16 modules, from customers and promotions to agents and shops, inventory, fuel and orders. Outside, it shapes the customer-facing products used by 1M+ households. We rolled it out on the internal tools first, then extended it to customers. I led the team of five designers who built it, ran it like a product, and measured whether people used it.

The problem: four squads, four versions of KOKO

KOKO's operations platform grew one module at a time: KOKO Point, MyKOKO, Customers, Promotions, Agents & Shops, Inventory, Fuel, Cooker, Field Systems, Orders and more, each shipped by one of four squads. Without a shared foundation, the same button, form field or alert was rebuilt slightly differently in each module, and inconsistencies usually surfaced after engineering had already built them.

For operations teams moving between modules all day, it felt like several products. For the business, it meant rework: time spent rebuilding work that should have been right the first time.

Why internal tools first. The operations platform had the most modules, the most drift and users we could reach directly, so it was the safest place to prove the system. Once components had held up across 16 modules, we extended Maridadi to the customer-facing products, where mistakes are more visible and harder to undo.

The problem: four squads, four versions of KOKO

For operations teams moving between modules all day, it felt like several products. For the business, it meant rework: time spent rebuilding work that should have been right the first time.

Foundations: every colour has a job

Maridadi's palette has seven ramps of 12 steps each, 84 colours in total, and five of those steps carry a semantic role that every component draws on.

Role	Token	Hex
Primary	KOKO Teal 6	#09DCFC
Secondary	KOKO Blue 10	#012FA2
Success	KOKO Green 5	#90C969
Warning	KOKO Yellow 6	#FFA800
Error	Red 6	#D42A2A

The 12-step ramps give each role light tints for backgrounds and dark shades for text and borders, so states like hover, pressed and disabled come from the same ramp rather than new colours. A neutral Grey 1–12 ramp handles surfaces, dividers and text.

Layout: a page template with the shared side navigation and a column grid, so every module starts from the same structure.
Swap slots: templates and dialogs use instance-swap placeholders, so designers drop in content without detaching the component.

Components built for every state

Maridadi's components cover every state an operations user can hit, not just the default.

Buttons: 120 variants. Four styles (filled, outline, ghost and link) come in three sizes and five interaction states, in a primary teal and a destructive red. Labels follow a verb–noun pattern, like "Save agent" or "Upload file", with optional leading and trailing icons.
Dialogs: a basic modal in two header styles, with a swap slot for the body so one component can hold a form, a confirmation or a table.
Feedback cards: info, success, warning and error messages, each mapped to its semantic colour and icon, with one clear action.

Each component's documentation covers when to use it, when not to, accessibility notes, and its matching component in code.

Five people, one system

Maridadi was a team effort. I took point in a team of 5 designers, and my job was to keep five people's work feeling like one system.

Direction and standards: I set the principles, the naming conventions, and the quality bar every component had to meet.
Ownership: foundations and component areas were split across the team, with a named owner for each, so everyone knew who to ask.
Embedded designers: each designer worked inside the squads and built components through live features, so the system grew from real needs and became part of delivery rather than extra work.
Critique and review: regular reviews caught drift before it reached the library.

Governance: releases, not live edits

We ran the library like a product with releases, so changes never reached designers' files without warning. Each change followed the same path:

Branch: every change was made on a Figma branch, never directly on main.
Review: the branch was checked for visual consistency, interaction patterns, accessibility and technical feasibility before merging.
Release: changes were published on a predictable cadence, each with a changelog saying what changed, why, and whether designers needed to act.
Breaking changes: changed props, renamed variants and restructured layers were announced in advance, tested in live files and shipped with migration notes, so designers could update at a sensible point in their sprint.
Deprecation: components were never deleted outright. They were flagged, moved to a deprecated page and linked to their replacement. After a sunset window, and once library analytics showed which files still used them, we helped those designers migrate before removing them. Engineering followed the same timeline.

Adoption: making the system the easiest way to ship

A design system only works if people use it, so I built adoption into how work got done and measured it on both the design and engineering sides.

Built into the workflow. Maridadi was linked to our DesignOps practice. Design system fluency is part of onboarding in weeks two and three. Design QA reviews every feature before handoff, and each review is tied to a Jira ticket and a Figma file. Using the system became the normal route to shipping.

Parity with engineering. Component names, props and tokens match between Figma and code. Engineers joined component reviews, and nothing was published without a feasibility check.

Measured:

Design: Figma library analytics for inserts, detach rates and which files used the library. A spike in detaches usually meant a missing variant, so it went on the roadmap.
Engineering: the share of UI built from coded components rather than one-off implementations, tracked through QA findings and code review.
Delivery: roughly 30% less design-to-development rework across four squads.

In use: onboarding a new agent

The Add Agent flow in the Agents & Shops module shows Maridadi at work. It's a two-step form: agent details first, then shop details, which can be added later so onboarding isn't blocked by missing information.

Almost every element comes straight from the system: the page template and side navigation, text inputs and selects with helper text, upload fields for the application form, national ID and KRA PIN, a toggle to link the agent's customer account, required-field markers, and a Cancel and Save & Proceed button pair. Building the screen was mostly assembly rather than designing from scratch, which is what the system was for. It is important to note that the same components then carried over to the customer side. The cooker and canister swap process shows the agent side of the same network.

Outcomes and what I learned

Roughly 30% less design-to-development rework across KOKO's four product squads.
One shared standard across 16 operations modules and the customer-facing products, still in use after I left.
A system that outlasted its builders: governance, documentation, and onboarding meant new designers could pick it up without relying on the people who built it.

What I took away:

Start where you can learn fastest. Internal tools let us prove the system with users we could reach directly before customers saw it.
Adoption follows usefulness, not mandates. Building components through live features did more than any rollout announcement.
Detaches are feedback. When designers broke away from a component, it usually meant the system was missing something.
Governance is what makes a system last. Branches, changelogs, and deprecation windows matter less on day one, but they're what kept Maridadi trusted as it grew.

This builds on earlier system work: Ajua's first design system, and design system governance across Safaricom's distributed, multi-team organisation.

Components built for every state

Maridadi's components cover every state an operations user can hit, not just the default.

Buttons: 120 variants. Four styles (filled, outline, ghost and link) come in three sizes and five interaction states, in a primary teal and a destructive red. Labels follow a verb–noun pattern, like "Save agent" or "Upload file", with optional leading and trailing icons.
Dialogs: a basic modal in two header styles, with a swap slot for the body so one component can hold a form, a confirmation or a table.
Feedback cards: info, success, warning and error messages, each mapped to its semantic colour and icon, with one clear action.

Each component's documentation covers when to use it, when not to, accessibility notes, and its matching component in code.

Five people, one system

Maridadi was a team effort. I took point in a team of 5 designers, and my job was to keep five people's work feeling like one system.

Direction and standards: I set the principles, the naming conventions, and the quality bar every component had to meet.
Ownership: foundations and component areas were split across the team, with a named owner for each, so everyone knew who to ask.
Embedded designers: each designer worked inside the squads and built components through live features, so the system grew from real needs and became part of delivery rather than extra work.
Critique and review: regular reviews caught drift before it reached the library.

Governance: releases, not live edits

We ran the library like a product with releases, so changes never reached designers' files without warning. Each change followed the same path:

Branch: every change was made on a Figma branch, never directly on main.
Review: the branch was checked for visual consistency, interaction patterns, accessibility and technical feasibility before merging.
Release: changes were published on a predictable cadence, each with a changelog saying what changed, why, and whether designers needed to act.
Breaking changes: changed props, renamed variants and restructured layers were announced in advance, tested in live files and shipped with migration notes, so designers could update at a sensible point in their sprint.
Deprecation: components were never deleted outright. They were flagged, moved to a deprecated page and linked to their replacement. After a sunset window, and once library analytics showed which files still used them, we helped those designers migrate before removing them. Engineering followed the same timeline.

Adoption: making the system the easiest way to ship

A design system only works if people use it, so I built adoption into how work got done and measured it on both the design and engineering sides.

Parity with engineering. Component names, props and tokens match between Figma and code. Engineers joined component reviews, and nothing was published without a feasibility check.

Measured:

Design: Figma library analytics for inserts, detach rates and which files used the library. A spike in detaches usually meant a missing variant, so it went on the roadmap.
Engineering: the share of UI built from coded components rather than one-off implementations, tracked through QA findings and code review.
Delivery: roughly 30% less design-to-development rework across four squads.

In use: onboarding a new agent

Outcomes and what I learned

Roughly 30% less design-to-development rework across KOKO's four product squads.
One shared standard across 16 operations modules and the customer-facing products, still in use after I left.
A system that outlasted its builders: governance, documentation, and onboarding meant new designers could pick it up without relying on the people who built it.

What I took away:

Start where you can learn fastest. Internal tools let us prove the system with users we could reach directly before customers saw it.
Adoption follows usefulness, not mandates. Building components through live features did more than any rollout announcement.
Detaches are feedback. When designers broke away from a component, it usually meant the system was missing something.
Governance is what makes a system last. Branches, changelogs, and deprecation windows matter less on day one, but they're what kept Maridadi trusted as it grew.

This builds on earlier system work: Ajua's first design system, and design system governance across Safaricom's distributed, multi-team organisation.

Download my Resume

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.

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.

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.