Banking · Oman · 2023
One design system, two brands, two languages
A bank in Oman needed retail and corporate banking rebuilt for two brands, on app and web, in Arabic and English. The go-live date was fixed before the work started.
- My role
- Design lead
- Team
- 10 designers
- Duration
- 3 months, discovery to handover
- Partner
- The core banking platform partner, who built it
- Surfaces
- Retail and corporate, app and web, two brands
The problem
The app was fast. People left anyway.
The bank came to us wanting a revamp of its retail, mobile and corporate banking for both its conventional brand and its Islamic banking brand. A seamless, consistent experience across every channel. A reasonable brief, and the kind every bank writes.
The behavioural data said something more specific. The app opened in 0.184 seconds. Login took another 0.218. Speed was not the constraint. Yet sessions ran five to six screens and timed out at five minutes, and in research we met a 58 year old woman who had given up on the app entirely and gone back to the website.
If an app is quick and people still abandon it, the problem is not performance. It is comprehension.
Discover
What the audit found
We ran a heuristic audit across the existing app and website before talking to anyone. The findings were structural rather than cosmetic.
- 01
Primary actions were not on the screenBottom navigation was given to History, Locator and Settings. The things customers actually opened the app to do were buried in an unprioritised menu.
- 02
Contrast failed WCAG AA and AAAHeavy use of grey text, and fat-finger targets on the header and homepage that misled people into the wrong action.
- 03
Errors were dead endsA failed task offered one button, OK. No way back to correct the mistake, and no message that made the person want to try again.
- 04
Nothing explained anythingHelp text was hard to find on both channels, which left customers guessing and discouraged them from learning.
- 05
The interface contradicted itselfTabs and callout buttons looked alike, fonts were mismatched, and whitespace was so loose the app read as empty.
Define
Five streams of research, run in parallel
Three months meant nothing could run in sequence. Our researchers ran quantitative and qualitative work at the same time as the competitive review, and I ran customer interviews alongside.
The competitive set deliberately reached past banking. Five primary comparators, then global banks, Indian banks, GCC banks and neobanks, each read against the same five parameters: out-of-the-box features, technical specification, usability, interface, and brand.
The customer quotes did more work than any of it.
“I once had the mobile app, but it does not work. I called customer service, and they would tell me to wait a few minutes, but nothing happened. So now I use the website.”
Female, homemaker, 58
“Changing passwords is challenging. It takes three to four attempts. There is nothing to tell me how many characters or special characters are allowed. I only see an error message after I have entered something it does not accept.”
Male, engineer, 42
“I have a loan. It does not show how much I have or how much I need to pay. I need that there. Then I do not need to go to the nearest branch to check.”
Male, IT professional, 42
The bank’s own data added a finding nobody had asked for. Customers between 24 and 49 are 81% of the registered base, but the under-18 group is 59% of potential new users and almost entirely unregistered. The product was being designed for the people already inside it.
Dream
Three pillars, each one traced back to something a customer said
Experience principles are usually decoration. These were derived, and we could point at the line of research behind each one, which is what made them survive argument later.
Intuitive
Becausepeople want simple, direct interactions in language they already know.
Familiar · Quick · Easy
Persuasive
Becausepeople want relevance and a human touch, not a form.
Personalised · Engaging · Human
Reassuring
Becausepeople want support when they need it, and a choice of how to reach the bank.
Reliable · Helpful · Secure
Those pillars drove specific decisions downstream: progressive disclosure to cut the number of screens in a session, conversational content instead of banking language, quick actions on the dashboard, and nudges that teach rather than sell.
Design
The hard part was not the screens. It was how many versions of each one existed.
Count the dimensions. Two brands, conventional and Islamic. Two channels, native app and responsive web. Two themes, light and dark. Two languages, English and Arabic, and Arabic mirrors the entire layout. Then multiply that by retail and corporate, which are different products with different users.
Designed naively, that is dozens of near-identical Figma files drifting apart from each other within weeks, on a project with no weeks to spare. It also had to sit inside the core banking platform’s component library, so we were not free to invent whatever we liked.
We built one system instead, on Figma variables. Components carry the structure. Variables carry everything that changes: brand colour, theme, and text direction. One component, swapped across every combination.
One component
- Structure
- Spacing and grid
- Type scale
- States and behaviour
Variables carry the difference
DiagramSixteen combinations of every screen, from one component. Built naively this is dozens of Figma files drifting apart inside a month. The original system pages will replace this diagram.
Information architecture covered eleven retail modules and fourteen corporate ones, the corporate side adding payee management, file upload, workflow approvals, trade finance and administration. Engineering reviewed the wireframes before the client did, so workflows were validated against what could actually be built before anyone debated how it looked.
The decision
We had two visual directions and picked the quieter one.
One direction was dark, high contrast, the next-generation-of-banking look that every fintech deck has. The other was light, green, warm, with illustration and what we called a delight factor. On instinct, the dark one looked more impressive in a pitch.
Customer interviews pointed the other way. People associated the lighter palette more directly with the brand, and we suspected a local factor too, since green sits in the Omani flag. I would not claim one single cause for it. What I can say is that the decision came from research, not from taste, and that is the part I would defend.
Before
- Primary actions buried below History and Settings
- Grey-on-grey text failing contrast standards
- Errors with a single OK button and no way back
- One visual language stretched across two brands
After
- Dashboard built around the tasks the data showed people do
- Contrast and target sizes taken to WCAG AA
- Errors that say what happened and offer the way back
- One system, brand and language swapped by variable
0000 0000 5678
EnglishThe default. Latin script, left to right.
0000 0000 5678
ArabicIdentical markup with the direction reversed. Every element mirrors, including the tab underline and the card.
0000 0000 5678
Islamic brandIdentical markup again. Only the brand variables change. Both brand colours here are indicative, not the client’s real palette.
ReconstructionDrawn in code for this case study, not a screenshot of the shipped product. All three are rendered from one template: the Arabic version is the same markup with the text direction flipped, and the third swaps brand variables only. Account numbers and balances are pinned left to right inside the Arabic layout, which is the bidi detail most teams miss. That is how the real system worked, so the demonstration is the argument. The original screens will replace these.
Develop
Tested with the people the personas described
We recruited against each of the six personas and watched them work through prototypes. The research was not a box to tick at the end: it ran inside the sprints, and what it found changed the rounds that followed.
Effective available balance
500,980.000OMR 1,129,877.700USDAccount statement
Pending approvals
ReconstructionCorporate is a different product from retail: approvals, statements and trade finance, used all day by people whose job this is. Drawn in code, awaiting the original screens.
Deliver
Where this story actually ends
We handed the designs, specifications and Figma assets to the platform partner, supported them through final review, and the engagement closed. They built it. The apps are live.
I do not have post-launch adoption numbers, and I am not going to borrow figures from an app that has shipped many releases since, built by another firm. What I can tell you is the starting point, 85,396 monthly active users on a product people were abandoning, and what we changed about it.
This is the ordinary shape of consulting work, and pretending otherwise would be the wrong lesson to draw from it. It is also the honest reason I want to move to a product company: I would like to find out what happened next.
Looking back
What I would do differently
Given three months and a fixed go-live date, very little. The constraint was real and the team hit it.
With more time, I would have spent it earlier, on wireframing and on the first UI concepts. A few decisions late in the project were settled by the calendar rather than by argument, and those are the ones I still think about. Not wrong, exactly. Just less examined than the rest.
The thing I would keep is the order we did it in. Engineering reviewed the flows before the client saw them, which meant the conversations with the bank were about whether the design was right rather than whether it was possible.