How ADCB Simplified Digital Onboarding With Hayyak

A customer can submit a banking application and still have work to do before using the account. ADCB’s Hayyak help page makes that distinction concrete. It explains that customers may be able to deposit money while withdrawals remain temporarily restricted pending document verification. It also describes a returning-user route for someone who left the application partway through. For a product team, both details matter. The experience needs to be easy to start, but it also needs to explain what the customer can do now and how to finish what remains. ADCB Hayyak help page

ADCB launched Hayyak in the UAE in February 2019 as a paperless account-opening app. The bank presented it as a way to apply and receive a debit card and cheque book without visiting a branch. In its 2024 annual report, ADCB described a subsequent upgrade that broadened the customer segments it could serve and moved the platform to a responsive web app. Those are different stages of the product’s life. The launch brought the application into a digital channel. Later work addressed the range of people and journeys that channel could handle. ADCB’s 2019 launch announcement · ADCB 2024 annual report

Design the work behind the form

Atefeh Fazaeli, who identifies herself as a senior product designer at Dubai studio Gravitas, describes her work on Hayyak in a public portfolio. She recounts bringing product, risk, operations and compliance into a workshop, then turning their requirements and exceptions into a single flow with owners for each step. Her account describes sequencing mandatory steps around what the customer is trying to do, and designing a document capture path that let customers retry when an image failed a quality check. The portfolio gives a practitioner’s account of the design work. ADCB’s own disclosures establish the launch and subsequent channel figures separately. Fazaeli’s Hayyak project account · Fazaeli’s professional profile

A team trying to simplify its own application can start by walking one example through the entire service with the people who own those decisions. Ask why each piece of information is needed, which service uses it and at what point it becomes necessary. A field that looks redundant may feed an essential decision. Another may ask the customer to enter data already available to the service. A product manager can separate those cases by recording the purpose and owner of each field before changing the form.

A journey map should also show what happens when a step cannot finish. Consider a fictional UAE customer who photographs an identification document in a dim room. The image passes through the camera screen but the text is unreadable. The first decision is where the service detects the failure. The next is what guidance the customer receives. A clear message can tell them which document to retake and why. A separate route can help when a retake cannot solve the problem. That design preserves the check while reducing time spent guessing what the service expects.

Let customers resume without losing the thread

ADCB’s Hayyak FAQ distinguishes new users from returning users and describes using a mobile number and following prompts to continue. A product manager can treat that kind of return as an expected part of onboarding. A person may need to find a document, wait for better light or leave the app to check a detail. The key design decision is which progress the service can safely retain and how it tells the customer what is still required. ADCB Hayyak help page

A resume screen can say which steps have been received, which still need action and where to continue. Let the application owner define how long a state remains useful. Information might expire or a requirement might change before the customer returns. Test the return path after an ordinary interruption and after a change that makes earlier information stale. A sensible response explains the single step to repeat and preserves other progress where permitted.

For the assisted route, have the customer and the person helping them work from the same underlying application state. Fazaeli describes designing an agent-assisted path alongside the customer experience. In another product, an agent might need to confirm that a document arrived without seeing all of its contents, or tell the customer that a case is in review without making a decision themselves. An operational test can give the agent a synthetic application and ask what they can verify, what they can change and when they must refer it to another team. Fazaeli’s description of assisted onboarding

Separate an open account from a useful account

The next design question is where to end the journey. A completed application gives the organisation a record. An open account gives the customer a product. A usable account gives them a way to do what they came for. Those events can happen at different times. ADCB’s Hayyak guidance distinguishes opening, document verification, delivery of the welcome pack and card activation in its answers. A support agent should be able to explain the distinction without promising that a later step has already happened. ADCB Hayyak help page

For an illustrative nonbank example, consider a Dubai business that sells software to shop owners. It can count workspace creation as sign-up, but a shop may get value only after it has added an item and completed a test sale. The product team can connect those events and see how many new customers reach the first useful action. If users complete sign-up and then stop at the item import, further simplifying the sign-up screen may leave the biggest obstacle untouched. A similar distinction in a bank is between creating an account and reaching the specific action the customer expected to use.

ADCB’s current guidance for people new to the bank directs them to its Mobile Banking App and asks them to choose an account type. The bank also documents an Instant Tourist Account through that app, with its own eligibility and a digital debit card that can be activated there. The tourist account is a separate product from the original Hayyak resident journey. The comparison shows why a shared entry point can still lead to distinct requirements and next actions. ADCB’s current onboarding page · ADCB Instant Tourist Account page

ADCB’s April 2026 Instagram reel introduces the separate Instant Tourist Account. The bilingual announcement shows how the bank described that product publicly. The product page provides the eligibility and operating details.

Read the channel figures with the right denominator

ADCB reports that more than 440,000 digital accounts were opened using Hayyak in 2024 and describes the channel as representing 79% of new-to-bank retail customers. Its 2024 annual report also puts straight-through processing for digital channels at around 80%. One measure is about how new business came in. The other is about how cases proceeded through digital processing. Neither measures what share of every application started in the app went on to become a usable account. The figures establish the scale of digital onboarding as reported by the bank. They do not isolate the effect of any single design choice. ADCB customers and communities disclosure · ADCB 2024 annual report

A product team can pair channel volume with counts for starts, submissions, decisions and first useful actions. Define the observation window before comparing groups. In an illustrative week, suppose 1,000 people start an application, 740 submit and 620 reach a defined first use within seven days. Submission is 74% of starts, while first use is 62% of starts. The 120 submissions without a recorded first use could include applicants awaiting review, people who were declined and customers with a usable product who have yet to act. Those groups call for different follow-up. Read the statuses before deciding which screen to change.

Review the spread of time as well as the rate. An ordinary application might finish in a short session while one referred for review takes much longer. An average can obscure the people waiting longest. Measure time spent completing steps separately from time waiting for another decision, and review a sample of interrupted cases with support. If the service completes more applications but staff now spend hours resolving failed document uploads, include that effort when judging the change.

Give the next improvement an owner

A product manager can make the next release small enough to evaluate. Pick a recurring failure, such as customers who cannot tell whether a document reached the service. Agree which system can confirm receipt, decide what the customer should see and define what support can verify. Release the change to a group the team can observe, then compare repeat attempts, support contacts and progress to the next step. Keep a view of who could no longer proceed, because a wording change can help one group and confuse another.

Fazaeli’s account describes a workshop that made requirements and ownership explicit. That is a useful starting point for this kind of improvement. Bring the team a real pattern from the funnel and a safe example of the customer experience. The design owner can make the message clearer, while operations checks that it reflects the decision the service actually made. Agree what happens if the check fails again. The work is finished when the customer and the next person helping them can both tell what happened and what to do next.

Before closing the release, give someone responsibility for watching the assisted queue. A change can move work out of the interface while increasing the number of cases staff need to interpret. Ask whether agents can resolve the new cases using the same information that drove the automated decision. If they regularly need a second team to explain it, the handoff is the next candidate for improvement. A weekly sample of cases that took longest can reveal the specific status, decision or missing piece of evidence causing the delay.

Keep the release notes tied to the actual journey the team tested. If the change covered one account type, record it at that level. The next team can reuse the method and test the differences for its own product, including any different documents or permissions. This makes the improvement useful beyond the original release without assuming that every applicant can follow the same route.