Take a business account application that already worked on the web and make it work on mobile. A company should be able to complete onboarding in about ten minutes, with owners anywhere, and without a bank employee ever meeting anyone.
NEO BIZ was a new product when I joined. The original journey served companies with layered ownership structures, companies owning companies, and verification happened the traditional way: a Relationship Manager visited the partners, or the partners came to a branch. Then the bank decided to build NEO BIZ Express: a faster journey for the simpler case, companies owned by individuals. That journey was designed and shipped on web first. My brief was to bring it to mobile. I owned that end to end, as sole designer, including the customer portal that shipped alongside it. On mobile the two are one: customers apply and track their application from the same app. A note on naming: the product is NEO BIZ Express on web and NEO BIZ Mobile on the app; the original layered-ownership journey remains a separate web product. A merge of the two systems is coming. And the ground here is completely different from Egypt. In the UAE, an Emirates ID does not need a human to verify it. The bank checks it against the official government gateway it is connected to: valid or not, expired or not. Sighting an original document in person is simply not a problem this journey has to solve. So the constraint moved somewhere else. Dubai is largely expatriate, which means the bank needs more than the ID: it needs the passport, and it needed the visa. That is the problem this journey actually solves.
Decision
Face recognition as a data shortcut, not a security gate
Emirates Face Recognition (EFR) is the mechanism. The customer uploads their Emirates ID and verifies against their own face; with their explicit consent, the bank retrieves the rest — passport and supporting details — automatically. This is worth naming precisely, because it is usually misread. EFR here is not a security checkpoint bolted onto the journey. It is a way to avoid asking the customer to upload documents they shouldn't have to upload. The identity check is already handled by the government gateway; EFR is what stops the customer from typing and scanning. Two things follow from that framing. The failure path is trivial by design. Liveness fails most often for ordinary reasons like glasses or poor lighting. So there are instructions before the attempt, and live guidance during it (move somewhere brighter). After three attempts, the journey stops trying: the customer uploads their passport and continues exactly as if EFR had succeeded. No slower queue, no manual review, no handoff to a human. Three tries with help, then a door, not a rejection. And the visa requirement was removed entirely. It was in the original scope. It came out once it was established that the passport alone confirms visa validity. A required document deleted is worth more than any screen improvement.
Decision
Remote verification, so nobody has to travel
This is the decision I am proudest of in this journey, and it was mine. The Express journey had a structural gap that survived into the mobile build: one person applies, but every Key Individual must verify and sign. On web that gap was still being closed the old way — by a Relationship Manager. I noticed it while working on mobile. So I proposed pushing verification to the person instead of asking that person to come in. The applicant generates a link; each Key Individual receives it, completes their own liveness check, and signs from wherever they are. This took the in-person meeting out of the journey, which was the point. The Relationship Manager still owns the relationship and still advises the customer. What went away was the appointment that had to be arranged around several people's calendars and locations before an account could move. Key Individual is the bank's unified term, chosen by the business and CX teams, and it covers two roles: Owner and PoA, the authorised signatory. Both must verify. Both do it remotely. And I lost half of this argument. I proposed the native share sheet: it's a phone, so send the link by WhatsApp, by message, by anything the person actually uses. Stakeholders liked the mechanism but not the channel. Communication had to stay official, so email. I still see no problem with share, and it is the first thing I would change.
Decision
The dashboard, and the two paths
The web journey is a stepper with four modules: Company, Ownership, Financial, Regulatory. On mobile it became a task dashboard: each module a card with its own state, business plan first. This is the pattern I later carried into the Egypt mobile design. It started here. Sole proprietorship and partnership run as two full paths, and the difference is not the product, it's the questions. In the regulatory section, "are you…?" becomes "is any of the partners…?", and a yes opens the details of that specific partner. Same screens, different interrogation. And where the journey can't serve you, it redirects rather than rejects. NEO BIZ Mobile covers companies owned by individuals. If an applicant declares that one of the owners is itself a company, which is layered ownership, the app doesn't say you are not eligible. It sends them to the web journey built for that structure. They can still return to the app afterwards to track that application and act on it. Only account opening for that case is absent from mobile, not the relationship.
Result · Live in production for more than a year and a half. And the comparison that matters most is with the sibling case file. Egypt and the UAE had the same regulatory requirement: every qualifying owner must be verified and must sign. Egypt has no verifiable digital identity, so that requirement produced six systems and a dedicated field team travelling with a tablet. The UAE has the infrastructure, so the same requirement produced a link in an inbox. Same designer, same requirement, two outcomes that look nothing alike. The difference isn't design ambition, it's what the country's identity infrastructure will let a design assume.
Read more