10

Ten practice tasks

Each task is sized to a focused half day. Treat them as briefs from a product partner: state the problem you are solving, propose a path, and defend the trade-offs. Success criteria are not a checklist; they are the standard you should meet to feel ready for review.

Task 01

Redesign the first transfer for a new customer

The first transfer a new ENBD X customer makes is the moment the app proves itself. Today the flow asks for a beneficiary, an amount, a purpose, and a confirmation. The customer is also subject to a cooling-off period on first sends to a new beneficiary, an OTP, and the realities of which payment rail will be used. Design the flow as if the bank had earned the right to ask less and explain more.

Method

Start by listing every input the bank actually needs and the regulatory or risk reason it needs them. Then sequence them. Decide which steps can be silent (rail selection, fee preview), which are explicit (amount, beneficiary, purpose, OTP), and which deserve a gentle pause (cooling-off, fraud check). Sketch two versions, one optimised for new-resident remittance, one for a domestic Aani transfer.

Success criteria

  • Each input is justified by a regulator, a risk reason, or a clear customer need.
  • Rail selection is invisible to the customer but visible to the team.
  • Cooling-off and OTP friction are framed as protection, not punishment.
  • The Arabic version mirrors cleanly with no orphaned arrows.
Task 02

Compose a Murabaha credit-card explanation screen

Design a single screen that a customer sees the first time they open an Emirates Islamic Sharia credit card. The customer should leave the screen understanding what makes the card different from a conventional one, what the profit rate represents, and what their obligations are if they revolve a balance. Avoid jargon. Avoid evasion.

Method

Start by writing two paragraphs of plain English explaining a Murabaha card to a friend. Edit them until they fit one screen. Then add the visual structure: a headline, a definition, a worked example with real AED figures, and a single "what changes if I delay a payment" panel. Translate to Arabic and review the parity of tone.

Success criteria

  • The screen survives a Sharia Supervisory Board review.
  • A customer who reads it can answer "is this interest" correctly without asking again.
  • The example uses realistic AED amounts that match retail card limits.
  • Arabic and English versions read with equal warmth.
Task 03

Design the dispute flow for a missing transfer

A customer claims a transfer went out and was not received by the beneficiary. They are anxious, possibly an hour into the problem. Design the in-app flow that takes them from the moment of doubt to the moment they feel held. The flow should respect CPR/CPS expectations on response timeframes and produce a record the operations team can act on.

Method

Map the customer's emotional arc first: confusion, frustration, fear, hope, resolution. Then map the operational arc: report intake, eligibility check, recovery initiation, status updates, outcome. Connect them with the smallest set of screens that lets the bank act and the customer feel informed.

Success criteria

  • The customer can file the dispute in under two minutes.
  • The flow gathers everything operations need without feeling like a form.
  • Status updates are proactive, not pull.
  • A real-person path is one tap away at every step.
Task 04

Reduce the OTP attack surface in a transfer flow

Look at every place a one-time password appears in a transfer journey. For each, decide whether it should remain, move to a stronger signing mechanism, or be removed. Where it remains, redesign the surrounding context so a customer who is being scammed has a real chance of pausing.

Method

List the OTP touchpoints across login, beneficiary creation, amount confirmation, and step-up checks. Categorise each by attack pattern. Propose the next state, then sketch the copy and the layout for the unavoidable surfaces. Run the copy past a colleague pretending to be a scam victim; iterate.

Success criteria

  • Total OTP surface area is materially reduced.
  • Remaining surfaces include explicit transaction context.
  • Scam-survivor copy reads as care, not blame.
  • The new flow does not violate any current CBUAE expectation on strong customer authentication.
Task 05

Design the first Aani-native moment in ENBD X

Aani allows a customer to be addressed by a mobile number or Emirates ID, request payment from another customer, and receive enriched data with the transaction. Design a moment in ENBD X that uses Aani's strengths rather than dressing them up as the old IBAN flow.

Method

Pick a real life moment: splitting a dinner bill, paying a freelancer, sending Eid money to a niece. Sketch the journey end to end. Highlight where Aani's instant settlement, addressing, or request-to-pay capabilities change the experience. Keep the IBAN path intact for customers who still want it.

Success criteria

  • Aani's strengths (addressing, instant, RTP) are visible to a non-technical customer.
  • The IBAN path is preserved without becoming the recommended choice.
  • The journey works in Arabic and in English with parity.
  • You can defend the choice of payment rail in a one-line statement.
Task 06

Improve the spend categorisation interface

Spend categorisation is a feature where AI quietly does most of the work. Most categorisations are right, some are wrong, and a few are unclassifiable. Design the interface so customers correct mistakes easily, the correction sticks, and the bank learns. Avoid accidentally training the system on noisy taps.

Method

Start with the moment of disagreement: a customer sees a transaction and does not recognise the category. Map the smallest correction gesture. Decide which corrections persist forever, which apply only to one transaction, and which propagate to similar future transactions. Surface the bank's confidence honestly without overloading the screen.

Success criteria

  • Correcting a category is a single gesture, no confirmation dialog.
  • The customer can express "this transaction" or "all similar transactions" with equal ease.
  • Confidence is visible without being intrusive.
  • The system gracefully handles unclassifiable transactions without forcing a guess.
Task 07

Onboard a non-resident family for cross-border banking

An expatriate ENBD customer wants to add their parents, who live abroad, as recurring transfer beneficiaries. Design the onboarding for those parents to receive money reliably, including the first send, recurring scheduling, FX awareness, and a way for the parents to confirm receipt without needing the bank's app themselves.

Method

Treat the family as a unit, not just two endpoints. Design for the customer (the sender) and the recipient (often outside the bank's app). Decide what is communicated to whom, in what language, on what channel. Make the FX margin explicit. Make the recurring schedule humane (avoid weekends, avoid holidays in either country).

Success criteria

  • A non-app recipient can confirm receipt without an account.
  • FX margin is shown alongside the amount, never hidden in fine print.
  • Recurring schedules avoid known weekends and holidays.
  • The journey supports at least Hindi or Urdu in addition to English.
Task 08

Communicate Open Finance consent to a sceptical customer

The bank is required to let customers grant a third party permission to read account data or initiate payments. Design the consent dashboard, the moment of grant, and the moment of revocation. Be honest about what is shared, who sees it, and how to undo it. Avoid the temptation to make the experience feel like a privacy policy.

Method

Map the data fields that can be shared, the actions that can be initiated, and the parties that might appear as third parties. Sketch the dashboard as the home of a customer's permissions, not a buried setting. Design the grant moment to match the third party's purpose, with clear scope and duration. Design revocation as a one-tap action.

Success criteria

  • The dashboard reads in plain language, not legal language.
  • Granting consent is purposeful and scoped.
  • Revoking consent is immediate and confirmed.
  • A customer can describe what they shared, in their own words, after one viewing.
Task 09

Design a calm fraud-stop moment

The bank's fraud system has paused a transfer that matched a known scam pattern. The customer is mid-action, possibly being coached by the scammer in real time. Design the screen that meets them. The screen should defuse the scammer's pressure, give the customer a clear reason to pause, and let them resume only with deliberate intent.

Method

Read transcripts of recent scam scripts (the bank's anti-fraud team will share). Identify the linguistic levers attackers pull (urgency, authority, secrecy). Build the pause screen as the counter-script: slow it down, name the pattern, offer a phone-the-bank path that goes through the bank's verified contact, and only then offer "I am sure, continue".

Success criteria

  • The pause screen explicitly contradicts at least three common scam levers.
  • The "verified contact" path is visibly more prominent than "continue".
  • "Continue" requires a deliberate gesture, not a default.
  • The screen reads with care for someone who has already made the decision; it does not blame.
Task 10

Write the trust statement for a new AI feature

Pick any AI feature you would propose to ship in the next quarter. Write the public-facing trust statement that accompanies it: what data the model uses, what it does with it, what it does not do, how the customer can correct it, how to turn it off, and what changes if they do. The statement should be readable in under two minutes and survive scrutiny by legal, risk, and a curious customer.

Method

Draft a one-page statement in the bank's voice. Walk it through the technical and risk team, the legal team, and a customer representative. Iterate. The final version should be the kind of document the bank publishes on its website without embarrassment.

Success criteria

  • The statement reads in under two minutes by a non-specialist.
  • Every claim about data and model is verifiable inside the bank.
  • The customer can opt out without losing access to the rest of the app.
  • The document is publishable as written.