Carry the same regulated journey — same documents, same declarations, same partner rules — through a device that gets picked up in a car, on a break, walking down a street, and put away again mid-sentence.
Context
The web journey assumes a sitting: a laptop, fifteen minutes, done. A phone assumes nothing. The customer starts on the way out of work, gets interrupted, returns two days later. The interruption is not an edge case on mobile — it is the expected behaviour. That reading of the environment was mine, and every structural decision in this chapter follows from it.
Nothing regulatory was allowed to move. The Central Bank's requirements, the document sets, the wet-signature ending — all identical to the web. The design question was never what the journey asks; it was how a person holds it.
Decision
The stepper became a dashboard
On the web, the journey is a five-stage stepper. On mobile I proposed a task dashboard: five cards — business plan, company profile, ownership, financials, regulatory declaration — each with its own state. The sequence did not change. Financials still cannot start before ownership, ownership before company profile. A module unlocks when the one before it completes; completed modules stay open for jumping back. What changed is the presentation — and the presentation is the point. A stepper shows remaining distance. A dashboard shows accumulated achievement. Same information, opposite feeling. On a device where the user leaves constantly, what greets them on return decides whether they continue: a stepper asks where was I? — the dashboard answers it before the question is asked. Three more things fell out of this decision: There is no review page. The web needed a long review screen at the end. Here the dashboard is the review — it shows what is complete and what isn't, and every finished module reopens for checking and editing, right up to submission. If an edit invalidates something downstream, that module returns to pending. A whole screen category, deleted by structure. The screen could never fit a stepper anyway. No horizontal room for stage tabs that tell the user where they are — the dashboard summarises each stage on its own card instead. And the first card is pre-won. The business plan choice was a fight: I proposed it as a dashboard step; the business didn't want it as one. The compromise shipped better than either position — the customer is routed straight into it after onboarding, before ever seeing the dashboard. So the dashboard's first appearance shows one of five already complete. The customer starts the heavy part of the journey already winning — invested, and measurably ahead. If they close the app before choosing, the card simply waits as an empty state.
Decision
The dropdown became a case matrix
On the web, company structure is one long dropdown — every legal form at once. Most applicants don't know these classifications; a long list makes them guess. On mobile I split the decision: single or partnership? — a question anyone can answer — and only then the forms belonging to that branch. The customer reaches a classification they couldn't have named, by answering questions they could. That principle then runs through the entire journey. The design is documented as a case matrix — company structure × nationality × residency × shareholder role × signing authority — and every combination has its own short path: an Egyptian shareholder, a non-Egyptian resident non-shareholder, an authorised signatory who holds no shares. Documents differ per path (national ID; passport; residency permit), contact details differ, and even the product offering differs — a single signatory gets a debit card and a cheque book; joint signatories get the cheque book only, because a debit card cannot carry two signatures. On the web, these branches were fields appearing and disappearing inside a page. On mobile, each branch is a sequence of one-question screens, each answer selecting the next screen. The cognitive load sits on the decision itself — never on re-reading a page that keeps changing shape. The required documents per entity type — partnership contracts and amendments for partnerships, articles of association for limited liability, professional licences where they apply — are the bank's regulatory reality, identical to the web. The design work was making each path feel inevitable rather than conditional.
Decision
Capture that prevents last year's failure
On the web, the commercial register broke after launch: owners kept each page as a separate file, uploaded only the first, and the OCR had nothing to read. The portal cleaned it up afterwards — after the effort had already landed on the customer. On mobile, the capture tool itself closes that door. Upload offers three native routes — photos, files, or camera — and the camera works like a document scanner: page, page, page, merged into a single file, uploaded once. Front-and-back documents like the tax card upload from photos just as directly. A tips sheet sits ahead of capture — formats, size limits, the owner's name matching the ID, stamp and validity requirements — the acceptance criteria surfaced before the attempt instead of arriving as a rejection after it. The web learned this failure in production. The mobile design absorbed the lesson before a single customer touched it. That, more than any screen, is what a second platform is for.
Result
No numbers — the app is designed and internally validated, awaiting its dedicated build team. Whatever is measured one day will be measured against the web journey's baseline, in its own results table.
What can be claimed now is the design itself: the same regulated journey, restructured around interruption — a dashboard that answers where was I, a case matrix that never asks the customer to know banking taxonomy, and a capture model that prevents the one failure the web had to learn in production.
Next chapter: Mobile Customer Portal — the waiting relationship, in the pocket.