The problem
Irembo had grown into a family of products; IremboGov, IremboApp, IremboPlus, and others. Each had been built with its own sign-in logic, suited to its own use case. Some required a verified National ID. Others just needed an email and password. A few had their own account management flows entirely.
For users, this meant managing separate credentials across products they thought of as one company. For Irembo, it meant maintaining parallel authentication infrastructure; costly, fragmented, and increasingly unsustainable as the product surface grew.
The deeper problem was one of trust and coherence. If a citizen was going to use Irembo to access government certificates, pay utilities, manage health insurance, and handle private subscription all in one ecosystem, they needed to feel like they were dealing with one platform that knew them. Not four platforms that happened to share a logo.
The design challenge
Building one account that worked across everything.
The user population spans an enormous range of needs and behaviours.
On one end: a citizen applying for a government certificate, who needs verified identity, formal language, and a process that feels as credible as visiting an office.
On the other: someone paying a TV subscription, who needs frictionless speed and would find a formal identity verification step intrusive and baffling.
The hardest design challenge was building something so seamless that the user would never notice it was there yet powerful enough to accommodate every use case sitting underneath it.
A user paying a TV bill and a user requesting a birth certificate are both using IremboAccount. They shouldn't feel like they're using the same thing. The platform has to read the context and shape itself accordingly, surfacing the right level of identity verification, the right language, the right friction without ever asking the user to understand why.
Starting with complaints and data
Before designing anything, we mapped where the existing multi-account experience was breaking down. User complaints and behavioural data told a consistent story:
Users were abandoning flows mid-way when asked to create yet another account or log in with credentials they'd forgotten. Support requests related to account access were high. Users who had successfully onboarded to one Irembo product were dropping off when they tried a second, not because the second product was bad, but because the account barrier felt like starting over.
The friction wasn't the product. It was the seam between products.
Mapping the use cases
The product spans genuinely different identity requirements. We mapped every major user journey across all Irembo products and identified what each one actually needed from an identity layer:
Some flows required full National ID verification, a hard requirement for government services where the state needs to know exactly who is making a request. Others required only a verified email. Others still needed neither, just a persistent identity for convenience and personalisation.
The design question was: how do you build one account model that satisfies all of these without forcing government-grade verification on someone who just wants to pay a bill?
The verification architecture
The answer was a tiered account model but one the user never experiences as tiers. From the user's perspective, they create one IremboAccount. Behind the scenes, the account holds whatever level of verified identity they've established, and each product surface requests only what it needs.
A user paying a TV subscription sees a standard sign-in. A user requesting a birth certificate is prompted to verify their National ID but only once, and only if they haven't already. After that, the verification is part of their account. Every subsequent government service they use feels instantly trusted.
The design principle: never ask a user to prove something they've already proven.
Designing for the invisible handoff
The trickiest interaction design challenge was the moment a user moves from a low-verification context into a high-verification one for the first time. If they encounter an identity gate mid-flow, having assumed they were already logged in, the experience feels like a wall.
We spent significant time on how to frame that moment: the language, the placement, the visual signal that this step is a one-time thing and not a recurring barrier. We tested several approaches. The version that performed best positioned the verification not as a requirement but as an upgrade, you're unlocking a new category of services which reframed the friction as a feature.
