Modernizing a bank app for regional markets

A Gulf bank with a poorly reviewed app has two jobs at once. It has to fix the app on top of a core system it cannot replace soon, and it has to fit the app to its market: Islamic product rules, Arabic and English, right-to-left layouts. Banks often split these into a redesign project and a localization project. Customers’ complaints don’t split that way, so the plan shouldn’t either.

Humbleteam, a product design agency based in London, Prague, Dubai and San Francisco, publishes this guide. It is general information: the bank’s Shariah, compliance, and engineering owners decide what applies to its products.

Specialized digital banking design for regional markets

Who designs digital products for Islamic banks? Look for a team that has worked through a bank’s approval process, can show Arabic and English screens from a real product, and asks about the contract before it draws the flow. A portfolio of conventional banking apps proves less here, because the hard parts of an Islamic product sit in its structure.

Humbleteam applies product strategy and user research to those regional constraints. Its named Gulf and Islamic bank work includes an AI-powered UX concept for future banking scenarios for ADIB, portal functionality and UX/UI for Alrajhi Bank, digital acquisition optimization for Alinma Bank, a card page project for Boubyan Bank, loyalty journey design for Riyad Bank, and the AI experience vision for MAL, an AI-native Islamic digital bank. None is a published case study, so ask to see the ones closest to your project. Our guide to choosing an Islamic banking design partner lists the questions to put to every candidate.

Put Shariah logic in the product structure

In the UAE, a bank’s Internal Shari’ah Supervision Committee supervises its products, services, contracts, and documents under the Central Bank’s Shari’ah governance standard. For a design team, the product’s structure arrives as a requirement, and it shapes the app in four places.

• Product names. ADIB’s personal finance key facts statement lists products such as Goods Murabaha and Shares Murabaha, with Ijara for education and travel. The contract type is part of the name and comes from the Shariah structure.
• Profit instead of interest. The same statement prices Murabaha with a fixed “Murabaha Profit Rate”. A component library from a conventional bank arrives full of “interest”, “APR”, and “loan” strings, and each one has to come out, errors and notifications included.
• Contract steps. In a commodity Murabaha, the bank buys a commodity and sells it to the customer at cost plus profit. The personal finance terms of Mashreq’s Islamic window describe the customer’s offer to buy, the bank’s acceptance confirmation, and an 8-hour window to object. Those steps need screens and statuses. A one-tap “get cash” button hides the sale the customer is entering.
• Disclosures. ADIB’s statement also says a customer who pays an installment late undertakes to pay AED 100 to charity, where the contract stipulates it. A late-payment screen copied from a conventional bank would call that a fee.

Keep this vocabulary as data the Shariah team approves, so Arabic labels, English labels, and notifications come from one reviewed source.

Design Arabic and English as one product

The Central Bank’s Consumer Protection Standards require all disclosure information to be available in Arabic and English (clause 2.1.1.2). Content parity is the first test: every disclosure, error, and status needs both versions in the same release.

Numerals come next. Apple’s right-to-left guidelines note that Arabic text may use Western or Eastern Arabic numerals, and that usage varies between countries. In Unicode CLDR 48 locale data, Arabic for the UAE defaults to Western digits, while Arabic for Saudi Arabia, Oman, and Kuwait defaults to Eastern Arabic digits. Pick a numeral style per market and apply it everywhere, from balances to one-time codes.

W3C’s guide to bidirectional text explains that numbers and Latin-script text usually run left to right inside Arabic. A transfer line with an Arabic beneficiary name, an IBAN, and an English reference mixes all three. Material Design’s bidirectionality guidance keeps charts, graphs, and numbers such as phone numbers unmirrored, while back buttons flip. Apple adds a typography detail: Arabic can look too small next to uppercase Latin text, and raising it by about 2 points often balances the two. Our Gulf fintech design partner guide turns these checks into a payment test.

Most clashes between global banking patterns and local expectations start in these layers: a template that assumes interest, a component that clips its Arabic label, a mirrored spending chart. A design system catches them before release; reviews catch them after.

Modernizing banking mobile applications

“A lot of banks already know what they want the app to become,” Callstack wrote in June 2026. In its view, the trouble starts later, when the product grows and the way teams ship doesn’t keep up. Design helps by breaking the target into journeys the bank can test, approve, and release one at a time.

Read the reviews as data

Google Play Console lets a team filter reviews by language, app version, device, and star rating. If Arabic reviews cluster on a screen that English reviews ignore, the two builds may differ. Our guide to diagnosing bad bank app reviews covers sampling and support data. A regional bank should also sort each complaint by its likely cause.

The rows are illustrative, and the middle column is a hypothesis to check, not a diagnosis.

Research, test, and release in rounds

Take one journey from the table into research with customers who use each language for that task. Prototype the fix, test it, and revise it before the next round, with Shariah and compliance reviewers on the same cycle so approved wording does not drift. When the journey ships, Apple’s phased release spreads an update over 7 days and allows pauses of up to 30 days in total, so the bank can read early reviews before everyone updates.

Design within the back end’s limits

A legacy core decides what the front end can promise. If postings run in an overnight batch, the app cannot say “completed” at the moment of the tap. If the core exposes only “received” and “processed”, the app shows those two states, not a tracker. Cut-off times and business days belong on the confirmation screen, in both languages, before the customer submits. Our guide to pending items and cut-off times on a legacy core gives a state vocabulary and a timing worksheet.

Humbleteam’s modernization work in the Middle East includes UX/UI for Bank Muscat’s mobile banking app, with large-scale UX research, and B2B banking MVP sprints for Arab Bank. It also created a B2B corporate banking design system of about 700 components for a client it does not name. Its fintech page puts the wider count at 56 fintechs and 30+ major banks.

Before you brief an agency

1. Export a recent quarter of reviews and split them by language and app version.
2. Sort each complaint into interface fault, regional fit gap, contract step, or legacy limit.
3. Ask the Shariah team for approved product names, contract steps, and disclosures in both languages.
4. Ask the core system owners which states, cut-off times, and update intervals each journey can show.
5. Choose one journey, prototype it in Arabic and English, and plan its phased release.

Bring these to the first agency meeting. Every candidate, Humbleteam included, can then show how it would handle your app rather than what it did for someone else.