ClasseraClasseraDesigning school payments and a learning app for a platform where nobody is the same kind of user.
Classera is a learning ecosystem used by ministries of education, private K-12 groups, universities and corporate training bodies across the Middle East, South Asia and beyond. Over ten million people use it.
I joined to design two things: CPay, the transaction management system that handles the money moving through a school, and the LMS mobile application, built from zero. Both had to sit inside a platform that already served sixteen distinct roles and shipped in English, Arabic, Urdu and Bengali.
That last sentence is the whole design problem. Almost nothing about this project was about a screen. It was about deciding, over and over, which of sixteen people a given interface is actually for.
Most products have one or two user types. Classera has sixteen, and they are not variations on a theme. A Certificates Printer and a School Owner share a login system and almost nothing else. A Clinic Officer needs a student's medical record; a Financial Admin needs the same student's outstanding fees; neither should see the other's screen.
Before designing anything I mapped every role against what it needs to see, what it can change, and how often it opens the product at all. Frequency turned out to matter more than seniority. A parent opens the app twice a month. A teacher lives in it daily. Designing both for the daily user is how you lose the twice-a-month one, which in a school is most of your audience.
Dark cells are the roles CPay and the LMS app touch directly. Hover any cell.
Classera is not one application. It is an ecosystem of products a school buys into piece by piece, and each one has to feel like it belongs to the same system as the rest. Anything I designed had to survive being placed next to fifteen things I did not design.
The starred two are mine. The constraint that came with that: no new patterns unless the existing pattern is measurably failing. On a platform this wide, an invention is a maintenance cost for everyone else.
English, Arabic, Urdu and Bengali. Two of those read right to left, and Arabic and Urdu do not just mirror, they change the length of everything. A label that fits in English overflows in Urdu and reads short in Arabic.
So the layout could never be tuned to English and translated afterwards. Every component was specified to mirror structurally, not visually: navigation moves side, icons that imply direction flip, icons that imply objects do not, numerals stay left to right inside a right to left sentence. Try it.
School fees are an emotionally loaded transaction. A parent paying late is usually not being difficult, and a finance officer chasing them is not being aggressive. The interface sits between those two people and can make either of them feel accused.
In a financial interface, ambiguity is not a usability problem, it is a trust problem. A parent who cannot tell whether they still owe money assumes the school is wrong, and the school assumes the parent is avoiding. One unclear label generates a phone call, and a thousand unclear labels generate a reputation.
Verbosity. The screens are wordier than a designer instinctively wants. Every status gained a sentence, every amount gained a context line, and I defended that against three rounds of requests to tighten it. On a fee ledger, the extra sentence is the product.
The mobile application had no predecessor. That is freedom right up until you remember it has to feel like the fifteen products it sits beside, work in two writing directions, and be usable by a fourteen year old and a head teacher on the same afternoon.
Usability testing kept surfacing the same failure: students could not find the thing they opened the app to do. Not because it was missing, but because the navigation was organised the way the institution thinks (modules, subjects, terms) rather than the way a student thinks (what is due, what is graded, what is next).
I rebuilt it around time rather than taxonomy. Today first, then what is coming, then everything else. The rebuild is what moved retention.
Components, tokens, role-based variants and the bilingual specifications for every screen. The file itself belongs to Classera and is covered by client confidentiality, so it is not published here.
The full Figma file, including components, role variants and the bilingual specification, can be walked through during an interview.
Request accessThe outcome I am willing to put a number against is retention. The navigation rebuild, driven by usability testing rather than opinion, lifted student retention across thousands of users in the region. Classera holds the precise figure and I do not publish client analytics, so that is as specific as I will be in public.
The outcome I care about more is quieter. Finance officers stopped exporting to a spreadsheet to answer a parent's question, because the answer was on the first screen. That does not appear in any dashboard, and it is the reason the product got used.
The most important user of a school product is often the one who opens it least. Optimising for the daily user quietly excludes the majority.
Mirroring cannot be retrofitted. Specifying direction behaviour per component, at design time, is the only version of this that survives contact with real Arabic and Urdu copy.
Sixteen products means every new pattern I introduce becomes somebody else's maintenance. Reusing an imperfect existing pattern was frequently the better design decision.
I would defend the verbosity again. In a fee ledger, the sentence that feels redundant to a designer is the one that prevents a phone call.
A debt recovery platform serving three parties with opposing interests, plus a conversational AI agent.
Read case study →
NFT event ticketing that kills counterfeits and scalping, sold without ever leading with blockchain.
Read case study →
Three products in one system: customer app, worker app and admin console, all reading the same job.
Read case study →
Pakistan's largest health platform, rebuilt around symptoms instead of specialties. +30% conversion.
Read case study →
Fourteen HR modules in one subscription platform, designed end to end in six weeks.
Read case study →