Mobil bankacılık uygulama tasarımı: ana akışlar nasıl kurulur?

Kısaca

Bir banka uygulamasında kullanıcının günlük işi birkaç akışa sığar. Giriş yapar, bakiyesine bakar, para gönderir, dekontu paylaşır ve bildirim alır. Bu sayfa bu akışları sırayla ele alıyor.

Para işleyen ürünlerin genel kurallarını fintech UX rehberinde anlattım. Hesap açma adımı KYC akışı sayfasında. Kullanıcıların en sık şikâyetlerini de ayrı bir yazıda topladım. Burada bunları tekrar etmiyorum.

Giriş ve biyometri

Banka uygulamasına girmek kısa bir iş olmalı. Bence her açılışta uzun bir şifre istemek kullanıcıyı kolay bir şifreye iter. Biyometrik giriş bu sürtünmeyi azaltır.

Türkiye'de bu konuyu BDDK'nın elektronik bankacılık yönetmeliği düzenler. Yönetmelik 15 Mart 2020'de Resmî Gazete'de yayımlandı. 39. madde mobil bankacılıkta kimlik doğrulamayı düzenler. Uygulamaya tanımlanan PIN ya da uygulamada kullanılan biyometrik bileşen, müşteriye özgü bir şifreleme anahtarına erişir. Anahtarla üretilen değer bankada çevrimiçi doğrulanırsa iki bileşenli kimlik doğrulama sayılır.

Aynı madde iki ayrıntı daha içerir. Cihaz üreticisinin kontrolündeki parola, PIN ya da biyometrik veri bu bileşenlerin yerine geçmez. Cihaz müşteriyle eşleşmişse hesap bilgisine bakmak ya da önceden güvenli tanımlanmış bir alıcıya ödeme yapmak için tek bileşen yeterli olabilir. Bilgileri görmek için ilk kez oturum açılıyorsa iki bileşen yine esastır. Son iki bileşenli oturumun üzerinden 90 günden fazla geçtiyse de öyle.

Yönetmeliğin 34. maddesi de tasarımı etkiler. Uygulamayı kurup etkinleştirmiş müşteriye giriş ya da işlem onayı için SMS ile tek kullanımlık şifre gönderilemez. İlk kurulum, etkinleştirme, yeniden etkinleştirme ve uygulamanın kullanılamadığı durumlar bunun dışında kalır. Başarısız giriş denemeleri de kullanıcıya sisteme ilk girdiği anda bildirilir.

Bu bir hukuki danışmanlık değildir. Ürününüz için güncel metni ve uyum ekibinizin yorumunu esas alın.

Tasarımda karşılığı

Android'in geliştirici belgeleri biyometrik istem için iki yol tarif eder. Biri, ekran kilidinin PIN, desen ya da şifresini de kabul etmektir. Diğeri, istem penceresine "hesap şifresini kullan" gibi bir alternatif buton koymaktır. Ben ikisinden birini her zaman isterim. Parmağı yaralı ya da yüzü maskeli bir kullanıcı uygulamanın dışında kalmamalı.

Aynı belge bir ayrım daha yapar. Varsayılan olarak sistem, biyometri kabul edildikten sonra kullanıcıdan bir onay hareketi bekler. Belgeye göre satın alma gibi hassas işlemlerde tercih edilmesi gereken bu yapıdır. Bakiyeye bakmak için açık onay gerekmeyebilir. Para gönderirken ise onay hareketi kalmalı.

Ana ekran ve bakiye gizleme

Ana ekranın işi tek bir soruyu cevaplamak: hesabımda ne kadar para var? Bakiye ekranın en üstünde, en büyük yazıyla durmalı. Altında son işlemler ve en sık kullanılan iki üç eylem yer almalı.

Bakiye gizleme bu ekranın en çok tartışılan ayrıntısı. Kullanıcı uygulamayı otobüste ya da kasada da açabilir. Bakiyeyi tek dokunuşla gizleyip gösteren bir anahtar, omzunun üstünden bakanlara karşı basit bir korumadır. Bence tercih bir sonraki açılışta da hatırlanmalı.

Ekran görüntüsü de bu başlığa girer. Android belgelerine göre FLAG_SECURE bayrağı ekran görüntüsünü ve pencerenin güvenli olmayan ekranlarda gösterilmesini engeller. Belge bunu banka uygulamaları için yararlı sayar. Bayrak açıksa, uygulama arka plandayken alınan görüntü de boş çıkar.

Bayrağı hangi ekrana koyacağınız bir tasarım kararıdır. Kullanıcı dekontun ekran görüntüsünü almak isteyebilir. O yüzden dekonta bir "Paylaş" butonu koyun, görüntü almaya mecbur bırakmayın.

Para transferi: IBAN, kolay adres ve kayıtlı alıcı

Para gönderme akışı uygulamanın en riskli yeridir. Kullanıcı burada üç şey seçer: alıcı, tutar ve gönderim yolu. Her birinde hatayı erken yakalamak gerekir.

IBAN alanı

Türkiye'de IBAN 26 karakterdir ve TR ile başlar. Wikipedia'daki ülke tablosuna göre ilk dört karakterden sonra 5 haneli banka kodu, 1 haneli ayrılmış alan ve 16 karakterlik hesap numarası gelir. IBAN geleneksel olarak dörtlü gruplarla yazılır, elektronik aktarımda boşluklar atılır.

IBAN, ISO 13616 adlı uluslararası standarttır ve içinde bir kontrol taşır. Doğrulamada ilk dört karakter sona taşınır, harfler sayıya çevrilir (A=10, Z=35). Ortaya çıkan sayının 97'ye bölümünden kalan 1 ise kontrol geçer. Kalan 1 değilse IBAN'da bir hata vardır.

Wikipedia'ya göre bu kontrol, atlanan, iki kez yazılan ya da yanlış yazılan tek bir karakteri yakalar. Yer değiştiren iki karakteri de yakalar. Uygulama bunu kullanıcı butona basmadan kontrol edebilir.

Alan dörtlü grupları kendisi oluşturmalı ve yapıştırılan boşlukları temizlemeli. Klavye ve alan tipi için mobil form klavyesi, hatanın ne zaman gösterileceği için satır içi doğrulama sayfalarına bakın.

Kolay adres ve FAST

TCMB'nin sayfasına göre FAST, TCMB'nin işlettiği ve ödeme talimatlarının 7/24, anlık gönderilebildiği bir sistemdir. 8 Ocak 2021'de işletime alındı. TCMB onu "EFT'den bağımsız bir sistem" olarak tanımlar. Erişim tarihimde işlem başına limit 300.000 TL idi ve TCMB bu limitin revize edilebileceğini yazıyor.

FAST'in Kolay Adresleme servisi IBAN yazmayı ortadan kaldırabilir. Kullanıcı kolay adres olarak cep telefonu, e-posta, T.C. kimlik ya da yabancı kimlik numarası tanımlayabilir. Vergi kimlik ve pasaport numarası da listede.

Telefon numarasıyla para göndermek hızlıdır ama alıcıyı görünmez yapar. Kullanıcı numarayı yanlış yazarsa başka birine para gönderebilir. Bu yüzden kolay adresle gönderirken de onay ekranında alıcının maskeli adını gösteririm.

Kayıtlı alıcı

Kira ya da aidat gibi düzenli transferlerde kullanıcı aynı IBAN'ı tekrar tekrar yazar. Kayıtlı alıcı listesi bu işi tek dokunuşa indirir ve yeniden yazma hatasını ortadan kaldırır. Kaydetme seçeneği ilk transferin içinde, alıcı adımında durmalı. Ayrı bir menüde arayan kullanıcı onu bulamaz.

Aşağıdaki demoda iki akışı karşılaştırabilirsiniz. İyi akıştaki IBAN kontrolü gerçek mod 97 hesabını yapıyor. Hesap sahibinin adı ise kurgusal.

Transfer akışı

JavaScript kapalı olduğu için canlı akış görünmüyor. Aşağıdaki özet, kötü ve iyi akışın dört adımdaki farkını anlatıyor.

İki akışın farkı, adım adım

1. Alıcı

   Kötü akışIBAN alanı düz bir kutu. Boşlukları ve biçimi kullanıcı kendisi çözüyor. Uygulama hiçbir şeyi kontrol etmeden sonraki adıma geçiyor.

   İyi akışIBAN yazıldıkça dörtlü gruplara ayrılıyor. 26 karakter tamamlanınca kontrol basamakları hesaplanıyor. IBAN geçerliyse hesap sahibinin maskeli adı görünüyor.

2. Tutar

   Kötü akışTutar yazıldığı gibi kalıyor. Kullanıcı bakiyesini görmüyor. Binlik ayıracı ya da kuruş yok, fazladan bir sıfır gözden kaçabilir.

   İyi akışKullanılabilir bakiye alanın üstünde. Yazılan tutar hemen altında TL ile biçimlenmiş olarak tekrar ediyor. Bakiyeyi aşan tutar daha bu adımda yakalanıyor.

3. Onay

   Kötü akışOnay ekranında yalnızca ham IBAN ve ham tutar var. Alıcının adı yok. Buton “Onayla” diyor, neyi onayladığınızı söylemiyor.

   İyi akışÖnce alıcının adı, sonra IBAN, en büyük yazıyla tutar. Ekran paranın saniyeler içinde gideceğini ve geri alınamayacağını söylüyor. Buton tutarı tekrar ediyor.

4. Dekont

   Kötü akış“İşleminiz gerçekleşmiştir” ve bir referans numarası. Kime, ne kadar, ne zaman gittiği yazmıyor.

   İyi akışDurum, tutar, alıcı, IBAN, tarih ve saat, işlem numarası tek ekranda. Alıcıyı kaydettiyseniz bunu da söylüyor.

Banka, isimler ve IBAN'lar kurgusaldır. Örnek IBAN kontrol basamağı hesabıyla üretildi, gerçek bir hesaba ait değildir. Demo hiçbir sorgu yapmaz, yazdıklarınız hiçbir yere gönderilmez ve saklanmaz.

Dört adımlı transfer: alıcı, tutar, onay ve dekont. Kötü akışta hiçbir kontrol yok. İyi akışta IBAN gerçek kontrol basamağı hesabıyla doğrulanır.

Onay ekranı ve geri alınamazlık

Onay ekranı, kullanıcının hatayı yakalayabileceği son yerdir. TCMB'nin sıkça sorulan sorular sayfasına göre FAST ödemesi saniyeler içinde alıcının hesabına geçer. Yanlış bir ödemede ise kendi finansal kuruluşunuzla iletişime geçmeniz gerekir. TCMB'nin iade süreçlerinde bir rolü yoktur.

Bu iki cümle onay ekranının tasarımını belirler. Para gittikten sonra uygulamanın elinde bir "Geri al" düğmesi yoktur. Ekran, kullanıcının bunu bilerek bastığından emin olmalıdır.

• Alıcının adı IBAN'dan önce gelir. Kullanıcı adı tanır, IBAN'ı okumaz.
• Tutar ekranın en büyük yazısıdır ve butonda tekrar eder: "15.000 TL gönder".
• Geri alınamazlık açıkça yazılır. "Gönderdikten sonra bu ekrandan geri alamazsınız" gibi tek bir cümle yeter.
• "Düzenle" yolu açık durur ve girilen bilgiler kaybolmaz.

Yönetmeliğin 34. maddesi ters yönü de düzenler. Elektronik kanaldan sunulan bir işlemin tersi yapılabiliyorsa ve risk artmıyorsa, banka bu ters işlemi aynı kanaldan sunmalıdır. Talimatın iptali gibi bir seçenek varsa kullanıcıyı şubeye göndermeyin. Onay ve geri alma arasındaki dengeyi fintech UX rehberinde ayrıca anlattım.

Android belgeleri yüksek tutarlı işlemler için ayrı bir yol da anar. Her kullanımda kimlik doğrulama isteyen anahtarlar, belgeye göre büyük bir ödeme gibi işlemlerde işe yarar. Ben bunu kullanıcının alışık olduğu tutarın üstündeki transferlerde düşünürüm.

İşlem dekontu

Dekont, transferin kanıtıdır. Kullanıcı onu ev sahibine, muhasebeciye ya da bir arkadaşına gönderir. Bu yüzden dekont hem ekranda hem paylaşılan dosyada tek başına anlaşılır olmalı.

Benim kontrol listem şu:

• Durum tek kelimeyle: gönderildi, bekliyor ya da reddedildi.
• Tutar ve para birimi, en büyük yazıyla.
• Alıcının adı ve IBAN'ı, gerekiyorsa maskeli.
• Tarih ve saat, dakikasıyla.
• İşlem türü (FAST, EFT ya da havale) ve işlem numarası.
• Açıklama alanına yazılan metin.

Dekont ekranında iki buton yeter: "Paylaş" ve "Ana sayfaya dön". Paylaş, dosyayı telefonun kendi paylaşım menüsüyle açmalı. Kullanıcı dekontu daha sonra işlem geçmişinden de bulabilmeli.

Bildirimler

Bildirimin içeriği için kontrol listesi fintech UX rehberinde var. Mobil bankacılıkta ayrıca düşünmeniz gereken yer kilit ekranıdır. Kilitli bir telefonun ekranındaki "Hesabınıza 12.000 TL geldi" yazısını yanınızdaki herkes okuyabilir.

Android belgeleri bunun için üç görünürlük düzeyi tanımlar. Herkese açık düzeyde bildirimin tamamı kilit ekranında görünür. Gizli düzeyde hiçbir şey görünmez. Özel düzeyde yalnızca simge ve başlık gibi temel bilgiler görünür, tam içerik görünmez. Bu düzeyde, bazı ayrıntıları gizleyen alternatif bir sürüm de tanımlanabilir.

Ben banka bildirimleri için özel düzeyi ve "Hesabınızda yeni bir işlem var" gibi bir genel sürümü öneririm. Belgeye göre son kararı yine kullanıcı verir. Tutarı kilit ekranında görmek isteyen bunu ayarlardan açabilmeli.

Bir tür bildirim ise beklememeli. Yönetmeliğin 36. maddesine göre banka riskli bir işlem tespit ettiğinde müşteriyi telefon ya da kısa mesaj gibi yollarla en kısa sürede uyarır. Bu uyarı kampanya bildirimleriyle karışmamalı. İzin isteme anı için izin ve bildirim ekranları sayfasına bakın.

Erişilebilirlik

Genel kuralları mobil uygulama erişilebilirliği rehberinde anlattım. Banka uygulamasında üç ayrıntıya ayrıca bakarım.

İlki bakiye gizleme anahtarı. WCAG 2.2'nin 4.1.2 maddesi (A), kullanıcının değiştirebildiği durumların programla ayarlanabilmesini ve değişikliğin yardımcı teknolojiye bildirilmesini ister. Ekran okuyucu "Bakiyeyi göster, anahtar, kapalı" demeli. Yalnızca bir göz simgesi yetmez. Web'de bunun karşılığı ARIA durum öznitelikleridir. Yukarıdaki demodaki akış seçicisi de bu yüzden basılı durumunu bildiriyor.

İkincisi IBAN ve tutarın okunuşu. 26 karakterlik bir IBAN'ı ekran okuyucuyla dinlemek yorucudur. Onay ekranında alıcının adı ayrı bir metin olarak durursa kullanıcı önce adı duyar. Tutar da "15.000,00 TL" gibi, para birimiyle birlikte metin olmalı.

Üçüncüsü biyometriye alternatif. Yüz tanımayı ya da parmak izini kullanamayan biri için PIN yolu her zaman açık olmalı. Bu yol bir ayar menüsünün dibinde saklanmamalı.

Benim notum

Bir banka uygulamasına baktığımda önce kendime küçük bir transfer yaparım. Akıştaki her ekranda tek bir soru sorarım: şu an parayı kime ve ne kadar gönderdiğimi biliyor muyum? Cevap bir ekranda bile "hayır" ise orayı düzeltmek gerekir.

Bence en tehlikeli boşluk, onay ekranında alıcı adının olmamasıdır. Başka bir mesajdan kopyalanan IBAN okunmadan onaylanabilir. Anlık transferde bu hatanın çözümü uygulamanın dışında, kullanıcının bankasıyla iletişime geçmesiyle başlar.

İkinci önerim, IBAN kontrolünü yerelde yapmak. Mod 97 hesabı birkaç satır koddur ve sunucuya gitmeden çalışır. Kullanıcı yanlış rakamı daha alan dolarken görür.