Maridadi: 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%.
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, 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 design of it, managing four designers, and we ran it like a product.
The problem: four squads, four versions of KOKO
KOKO’s operations platform grew one module at a time, 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 the 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.
We started with internal tools because they had the most modules, the most drift and users we could reach directly. Once components held up across 16 modules, we extended Maridadi to the customer-facing products, where mistakes are more visible and harder to undo.
The system: every colour has a job, every state is covered
The palette has seven ramps of 12 steps, 84 colours in total, and five of those steps carry a semantic role that every component draws on. Hover, pressed and disabled states come from the same ramp rather than new colours.
Components cover every state an operations user can hit, not just the default. Buttons alone come to 120 variants: four styles in three sizes and five interaction states. Templates and dialogs use swap slots, so designers drop in content without detaching the component. Each component’s documentation says when to use it, when not to, and what its matching component in code is.
The button matrix: four styles, three sizes, five interaction states.
The same shop page with kit replacements set to No (left) and Yes (right): the status badge appears beside the shop name.
A destructive action: the dialog says what will happen and that it cannot be undone, and keeps the red Reset button apart from Cancel.
Team and governance
My job was to keep the whole team’s work feeling like one system. I set the principles, naming conventions and quality bar, and each foundation and component area had a named owner. Designers 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.
We released the library like a product. Every change was made on a Figma branch, reviewed for consistency, accessibility and technical feasibility, and published on a predictable cadence with a changelog. Breaking changes were announced in advance with migration notes. Components were never deleted outright: they were flagged, linked to their replacement, and removed only after a sunset window, once library analytics showed who still used them.
Adoption: the easiest way to ship
I built adoption into how work got done. Maridadi was linked to our DesignOps practice, design system fluency is part of onboarding, and Design QA reviews every feature before handoff, tied to a Jira ticket and a Figma file. Component names, props and tokens match between Figma and code, and engineers joined component reviews.
The Add Agent flow shows it in use. Almost every element comes straight from the system, so building the screen was mostly assembly rather than designing from scratch. 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 the people who built it.
What I took away: adoption follows usefulness, not mandates, and building components through live features did more than any rollout announcement. Detaches are feedback, because when designers broke away from a component it usually meant the system was missing something. And governance is what makes a system last. Branches, changelogs and deprecation windows matter less on day one, but they 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.
Want to talk about this project, or work together?