How to select a design partner for Islamic banking modernization

An Islamic bank should select a design partner that can work with its Shariah governance process, explain complex products clearly, and design around its existing systems. The shortlist needs evidence of those capabilities and named specialists for the institution’s market.

A generic banking portfolio provides a starting point. The evaluation must go further when the product has a particular contractual structure, approval sequence, or disclosure requirement. Those details belong in discovery before the agency proposes a new application flow.

What expertise does Islamic banking product design require?

The bank should ask candidates for a relevant project and a precise account of their role. Useful evidence includes a product journey, examples of terminology reviewed by the institution, and an explanation of how the design team handled requested changes. Confidential work may require a reference conversation. An agency should identify the limits of what it can substantiate.

Governance varies by institution and jurisdiction. In the UAE, the Central Bank’s Higher Shari’ah Authority describes its role in standardizing Islamic financial practices, including the adoption of AAOIFI Shariah standards and UAE-specific resolutions. The institution’s specialists must determine the requirements that apply to its product. A design team should document and implement their decisions.

A DIFC project also needs a precise jurisdiction check. The Dubai Financial Services Authority regulates financial services conducted in or from the DIFC. A reference to “Middle East compliance” is too broad to define a scope of work. The bank should specify the regulated entity, activity, customer group, and responsible reviewers.

For an illustrative financing application, the design brief could require the team to establish:

• The product terms and customer obligations that need explanation before an application proceeds.
• The points at which the customer receives documents, accepts terms, or authorizes an action.
• The product information and wording that the bank’s specialists must approve.
• The permitted path when the customer changes an amount, abandons the application, or returns after a review.

The institution supplies the contractual meaning. Researchers can then test whether customers understand it. If participants misunderstand a label, the next step is a wording or sequence review with the appropriate specialist. Research findings should never silently change the product’s approved terms.

How should an agency approach a poorly reviewed legacy app?

A redesign should begin with a diagnosis of the complaints. The team can group recent reviews by task, app version, and device, then compare them with support records and service data. Reviews reveal where to investigate; they do not establish that every reported problem has the same cause.

For example, a customer may describe a financing application as “stuck.” Research might reveal an unclear document request, while operational records show that the application awaits a review. The design needs to explain the actual status and available next step. Redrawing the progress indicator would leave the customer with the same unanswered concern.

A useful banking app audit produces a short, evidence-backed list of journeys to fix. Each finding should include the observed behavior, the affected customer task, and any dependency on a service or policy change. Product owners can then choose a pilot that has both a meaningful customer benefit and a feasible implementation path.

Research recruitment should reflect the bank’s customers, including their language needs, familiarity with the financial product, and accessibility requirements. A participant who has used the bank for years may rely on labels a new customer cannot interpret. The redesigned experience needs to account for both groups.

Humbleteam’s fintech work includes developed and user-tested prototypes for ING’s small-business banking concept. Its One Bank case documents banking interface and brand design. These provide material for evaluating research and UX/UI work; Islamic product expertise requires its own evidence in the selection process.

How can the design project preserve operational stability?

The bank and agency should map each customer action to the systems and people behind it. A new application, a document replacement, or a changed repayment instruction may follow different approval paths. Designers need to know where the record lives, which system confirms the result, and what support can see while work is pending.

Security and compliance reviewers should join at defined decision points. A shared decision record can connect each approved requirement to the related screen, document, and test. This gives implementation teams a way to resolve conflicting comments and helps reviewers see whether a later design change affects an earlier approval.

The pilot should include interrupted sessions and unsuccessful outcomes. A customer who returns after a timeout needs an accurate status and a safe way to resume. The agency should demonstrate what happens if a requested document has already been received or a processing service is unavailable. Engineering must confirm the recovery behavior before it reaches customers.

Procurement should also establish who owns production testing, migration, and support preparation. A phased release may allow the institution to inspect a limited journey before expanding the redesign. The bank’s release owner should approve that approach and the conditions for stopping or reversing it.

The final handoff should contain the approved journey, reviewed content, dependency map, research findings, and implementation acceptance criteria. Open questions should have named owners and dates. A screen set alone leaves the bank to reconstruct the product and governance decisions that made it usable.