Overview
MoMo is MTN's mobile money platform. People use it to send money, pay bills, buy airtime, save, borrow and run their business, across many African markets. Different teams build MoMo products on different platforms: web apps, mobile apps, and mini programs that run inside the MoMo super app. Neo is the MoMo design system. The design system team had already designed it in Figma: colours, type, spacing and a large set of components, from buttons and inputs to wallet and payment cards. My job was to turn that Figma file into code that every team could use, so a button in a mini program looks and behaves exactly like a button in the MoMo app or on the web. I started in July 2026. Since then I have built the library on three platforms, written the docs, set up the release process and started working with the developers who use it.
RoleDesign Engineer
ClientMTN Group Fintech (MoMo)
TimelineJuly 2026 to now
PlatformsWeb, React Native, MoMo mini programs
ToolsFigma, TypeScript, React, React Native, Storybook
The problem
MoMo isn't one app. It's a family of products built by different teams, on different platforms, at different speeds. Without shared code, each team rebuilt the same buttons, inputs and cards from the Figma file. Every rebuild was a chance for small differences to creep in: a slightly different blue, a different corner radius, an error state that worked one way here and another way there. For a money app, that matters. When a screen looks off, people trust it less. Having a design system only in Figma wasn't enough. Developers still had to translate every component by hand, and the design and the code drifted apart from day one.The question I had to answerHow do I turn one Figma design system into code that teams on every platform can use, that always matches the design, and that stays in sync as it changes?
My role
I'm the design engineer on Neo. I sit between the design system team, who own the Figma file, and the developers who build MoMo products. In practice that means:- Building the components on all three platforms, matched to the Figma designs.
- Designing the architecture: how the library is split, and how design decisions flow from one place into every platform.
- Writing the documentation: a clear usage guide for every component.
- Shipping it: versioning, release notes and visual review before anything goes out.
- Supporting adoption: talking to developers who use Neo, finding what gets in their way and planning what to build next.
How Neo is built
The most important decision was to keep everything that isn't platform-specific in one shared foundation, and have every platform build on top of it. The foundation holds the design tokens, the brand font, the icons and the rules for how each component behaves. Each platform then turns those into components that feel native to it. Because the foundation is shared, a component works the same way everywhere. A developer who has used Neo on the web already knows how to use it on mobile or in a mini program, and a designer can trust that the same component means the same thing on every screen.Tokens: the brand in one place
Every visual decision in Neo comes from a token: the MoMo blues, Sunshine Yellow, the neutral greys, and the colours for errors and success. Typography and spacing work the same way. The rule I hold myself to: if a token exists for a value, nothing is hard-coded. That holds on every platform. If the brand blue changes, it changes everywhere on the next release.From Figma to code
Components come across from the Neo Figma file one at a time. I use an AI-assisted workflow for this, but with a strict process, because code generated from a design file is only a starting point.01. Read the designI start from the Figma design, then check icons and colours against the real assets and screenshots. I don't trust generated code as it is. If a variant makes no visible difference, I note it rather than build something that doesn't matter.
02. Plan before buildingBefore writing any code I decide what the component needs to do, which styles are reused and which are new, and why.
03. Build in orderThe shared foundation first, then each platform in turn. Each step builds on the one before, so the platforms can't disagree.
04. Check every stateI check every state side by side against the Figma design. A component isn't done until every state matches.
Design decisions that shaped the library
Nothing only looks interactive
Every interactive part of a component, like a toggle, an expand and collapse, or a masked card number, is controlled by the screen that uses it. If something looks tappable, it does something, and the product team is always in control of what.Text fields that know where you are
Text fields work out how they should look on their own: focused while someone is typing, complete once there's a value, and back to default when they're empty. Errors and disabled states come from the screen, because only the screen knows about them. The same rule applies on every platform, so fields behave the same everywhere.Built for many markets
MoMo runs in many countries, so components are built with different languages and partners in mind. Sensitive details like card numbers can be shown, masked or hidden, depending on what the screen needs.Bringing Neo to mini programs
Mini programs were the hardest platform. They run inside the MoMo super app on a different framework with its own way of building screens, so I couldn't reuse the web or mobile code. What I could reuse was the shared foundation. I rebuilt the components for mini programs so they look and behave like the mobile versions, with styles that still come straight from the design tokens. I also worked around the platform's limits, for example making sure icons keep the right brand colours, and that the brand font loads quickly without making people wait. Every mini program component can be previewed next to its mobile version, so I can compare them directly.Documentation developers actually use
The docs live in one place that shows every platform side by side. Every component has a usage guide written to the same structure:- A short overview
- When to use it, and when not to (with the alternative to use instead)
- Do and don't guidelines
- A working example developers can start from
- Every state of the component, live
Shipping and versioning
A design system only helps if teams can trust its releases. I set up a release process where every version comes with notes on what changed and whether it's safe to upgrade, and where visual changes to components are reviewed and approved before they ship. Teams only take on the components they actually use, so adopting Neo doesn't slow their apps down.Listening to the developers using it
Once teams started building with Neo, I wanted to know what was working and what wasn't. I wrote an adoption check-in for developers with questions grouped by theme: getting started, finding components, docs, design fidelity, updates, performance and accessibility. Every question is tied to how Neo actually works, so every answer points to a change I can make. One question I pay close attention to: have you copied a Neo component into your own code to change it? If people copy components, the library isn't covering real needs.Planning for teams that need to diverge
That question led to an architecture proposal I wrote for the team. Some libraries hand you their source code to edit freely. That's flexible, but for a company design system it's risky. Every copy drifts, and a fix to one component no longer reaches every app. I recommended a hybrid. The shared library stays the default. When an app really needs to own a component, it can take just that one, while the brand foundation always stays shared. That way a brand change still reaches everyone.Lighter fixes firstBefore a team takes its own copy, make the library easier to adjust, so small design tweaks never need a copy at all.
Copying as a last resortWhen a team does need its own version, it's tracked back to where it came from, so it can still be compared with the latest release.
Copies as signalsIf several apps need their own version of the same component, that's a feature request. The fix goes into the library and those apps switch back.
Drift you can seeA simple report shows which apps have their own versions and how far behind they are.
Challenges
Three platforms, one behaviourEach platform handles styles, images and fonts in its own way. Keeping behaviour identical meant pushing every shared decision into the foundation.
A platform with its own rulesMini programs couldn't reuse the web or mobile code, so they needed their own approach while still matching the design exactly.
Fidelity at scaleWith many components and many states each, design drift is easy. Checking every state against Figma and reviewing visual changes before release kept it in check.
Consistency versus flexibilityTeams want freedom, and the brand needs consistency. The hybrid proposal is my answer to keeping both.
Outcome
Neo has gone from a Figma file to a working, versioned library on three platforms. MoMo teams can pick it up, read a usage guide and ship screens that match the design, whether they're building for the web, a mobile app or a mini program. Brand decisions now live in one place, and a change there reaches every platform on the next release. The work is ongoing. Next up are the results of the adoption check-in and the first steps of the customisation plan.Skills & deliverables
- Design system engineering across web, React Native and mini programs
- Design tokens and shared component behaviour
- Figma to code with an AI-assisted, review-first workflow
- Component documentation and usage guides
- Release and visual review process
- Developer research and adoption planning
- Architecture proposal for component distribution
