Fintech UX: para işleyen uygulamalar nasıl tasarlanır?

Kısaca

Fintech uygulama tasarımında tek bir soru her ekranı yönetir: kullanıcı bu ekranda parasını kaybedebilir mi? Cevap evetse, o ekran diğerlerinden daha fazla özen ister.

Bir e-ticaret sitesinde yanlış ürünü sepete atmak küçük bir sorundur. Yanlış IBAN'a para göndermek ise günlerce süren bir uğraşa dönüşebilir. Fintech UX'in işi, bu iki hata arasındaki farkı tasarıma yansıtmaktır.

Para işleyen bir ürüne baktığımda altı alanı ayrı ayrı kontrol ederim. Aşağıdaki başlıklar bu sırayı izliyor. Kullanıcıların neden şikâyet ettiğini ayrıca mobil bankacılık şikâyetleri yazımda topladım.

Güven neyle kurulur

Kullanıcı bir fintech ürününe, her dokunuşta ne olacağını önceden bildiğinde güvenir. Para ekranında beklenmedik her şey kaygı yaratır.

Jakob Nielsen'in 10 kullanılabilirlik ilkesinden ilki burada temel kuraldır: sistem, olup biteni kullanıcıya makul sürede ve uygun bir geri bildirimle haber vermelidir. Para ekranlarında bunun somut karşılıkları şunlardır:

• Ücret, komisyon ve kur, butona basmadan önce ekranda görünür. Dekontta ilk kez görülen bir ücret, kullanıcının bir daha o ekrana güvenmemesine yeter.
• İşlemin durumu açıkça söylenir: gönderildi, bekliyor ya da reddedildi. "İşleminiz alınmıştır" bu üçünden hangisi olduğunu söylemez.
• Bakiye, işlemden sonra hemen güncellenir. Güncellenemiyorsa bunun nedeni ekranda yazar.
• Dil sade kalır. "Havale/EFT talimatınız işleme alınmıştır" yerine "1.500 TL, Ayşe Y.'ye gönderildi" yazmak daha kısadır ve daha çok şey söyler.

Güveni bozan bir şey daha var: kullanıcıyı yönlendiren arayüz hileleri. Önceden işaretli bir sigorta kutusu ya da gizlenmiş bir iptal yolu kısa vadede satış, uzun vadede şikâyet getirir. Bu kalıpları dark pattern rehberinde tek tek anlattım.

KYC ve kimlik doğrulama

KYC (know your customer, "müşterini tanı"), bir finans kuruluşunun müşterisinin kimliğini doğruladığı süreçtir. Kullanıcı için bu, hesap açarken kimlik kartını ve yüzünü kameraya göstermek demektir. Bazı ürünler buna görüntülü görüşme ekler.

KYC adımında kullanıcı ürünü çoğu zaman henüz kullanmamıştır, ama en çok bilgiyi o anda verir. Bu yüzden bu adımı onboarding'in en kırılgan yeri sayarım. Kendi işlerimde şunlara bakarım:

• Başlamadan önce ne gerektiği söylenir: kimlik kartı ve iyi bir ışık. Böylece kullanıcı yarı yolda kartını aramaya gitmez.
• Her belgenin neden istendiği bir cümleyle açıklanır.
• Kamera ekranı canlı geri bildirim verir: "Kartı çerçeveye yaklaştırın", "Işık yetersiz". Yalnızca "Doğrulama başarısız" demek, kullanıcıyı aynı hatayı tekrarlamaya iter.
• İlerleme kaydedilir. Uygulama kapanırsa kullanıcı baştan başlamaz.
• Kamera kullanamayan biri için başka bir yol vardır ve bu yol saklanmaz.

Giriş ve işlem onayı

Türkiye'de elektronik bankacılığı BDDK'nın 15 Mart 2020'de Resmî Gazete'de yayımlanan yönetmeliği düzenler. Yönetmeliğin 34. maddesi, birbirinden bağımsız en az iki bileşenden oluşan kimlik doğrulama ister. Bu bir hukuki danışmanlık değildir; ürününüz için güncel metni ve uyum ekibinizi esas alın.

Tasarım açısından asıl soru, bu güvenlik adımlarının kullanıcıyı ne kadar yorduğudur. WCAG 2.2'nin 3.3.8 maddesi (AA) bu konuda net: W3C'nin açıklamasına göre SMS ile gelen doğrulama kodu en azından yapıştırılabilmelidir. Kodun elle yeniden yazılmasını zorunlu tutan bir servis bu maddeye uymaz.

Aynı açıklama, şifre yöneticisiyle doldurmayı ve kopyala-yapıştırı da bu maddeyi karşılamanın yolları arasında sayar. Şifre alanında yapıştırmayı engellemek güvenlik gibi görünür. Bana kalırsa kullanıcıyı yalnızca daha kısa, kolay hatırlanan şifrelere iter.

Oturum süresi de bu başlığa girer. Kullanıcı fatura numarasını bulmaya gidip döndüğünde oturumu kapanmışsa, yazdığı her şey kaybolur.

WCAG 2.2'nin 2.2.1 maddesi (A) bunun için bir yol tanımlar: süre dolmadan kullanıcı uyarılır. Süreyi basit bir hareketle uzatması için ona en az 20 saniye tanınır.

Para akışlarında onay ve geri alma

Para gönderme ekranında hatayı iki araç yakalar: onay ve geri alma. Onay, hatayı işlem olmadan önce yakalamaya çalışır. Geri alma ise hata olduktan sonra kullanıcıya bir çıkış verir.

Nielsen'in üçüncü ilkesi bu çıkışı ister: kullanıcılar sık sık yanlışlıkla bir şey yapar ve istemedikleri bir eylemden uzun bir süreç olmadan çıkabilmelidir. Beşinci ilke hata önleme üzerinedir: hataya açık koşulları ortadan kaldırmayı ya da işlemden önce kullanıcıdan onay almayı önerir.

WCAG 2.2'nin 3.3.4 maddesi (AA) bunu finansal işlemler için açıkça yazar. Kullanıcı adına finansal işlem yapan sayfada şunlardan en az biri olmalıdır:

• Gönderim geri alınabilir.
• Girilen bilgi hatalara karşı kontrol edilir ve kullanıcıya düzeltme fırsatı verilir.
• İşlem kesinleşmeden önce bilgiyi gözden geçirme, onaylama ve düzeltme imkânı vardır.

Onay ekranı nasıl çalışır

Nielsen onay pencereleri üzerine yazısında şunu söyler: her işlemde onay sorarsanız kullanıcı okumadan geçmeyi öğrenir. Bu yüzden "Emin misiniz?" diye soran genel bir pencere kimseyi korumaz.

Önerileri fintech'e birebir uyar. Onay ekranı, kullanıcının isteğini tanıtıcı ayrıntılarla yeniden söyler. Butonlarda "Evet / Hayır" yerine ne olacağını anlatan etiketler bulunur.

Yazıda bir banka örneği de var. Onay, yalnızca kullanıcının alışık olduğu ödeme aralığının en az iki katı olan ödemelerde istenebilir. Nielsen bu eşiğin bir örnek olduğunu, gerçek değeri kullanıcı araştırmasının belirlemesi gerektiğini ekler.

Bir transfer onayında kullanıcının kontrol etmesi gereken iki şey vardır: kime ve ne kadar. İkisi de ekranın en görünür yerinde durmalı.

• Kime: Kimse IBAN'ı karakter karakter okumaz, ama hesap sahibinin maskeli adını bir bakışta tanır. İngiltere'de Confirmation of Payee adlı hesap adı kontrolü 2020'den beri çalışıyor. Pay.UK bu kontrolü, yanlış hesaba giden ödemeleri azaltmak için tasarlanmış bir servis olarak tanıtıyor.
• Ne kadar: Tutar büyük yazılır ve butonda tekrar eder. Kullanıcının alışık olduğu aralığın dışındaysa ayrıca uyarılır.

Geri alma penceresi

Nielsen aynı yazıda onay pencerelerinin kullanıcının iş akışını yavaşlattığını yazar. Geri alma sunmak için çok çaba harcanmasını da önerir.

Para karşı hesaba hemen geçiyorsa geri almanın yeri kalmaz. Geri alma, ancak gönderim kısa bir süre bekletilirse mümkün olur.

Bu bekleme bir ürün kararıdır ve her işleme uymayabilir. Bence kayıtlı bir kişiye para gönderirken birkaç saniye beklemek kullanıcıyı pek rahatsız etmez. Bir hatayı yakalamaya ise yeter.

1. AlıcıIBAN ya da kayıtlı kişi seçilir.
2. Ad kontrolüHesap sahibinin maskeli adı gösterilir.
3. Tutar tekrarıTutar büyük yazılır, olağandışıysa uyarı çıkar.
4. Gönder ve bekleKısa bir geri alma süresi başlar.
5. DekontBildirim ve işlem geçmişi aynı bilgiyi verir.

Şekil: Bir para transferinde kullanıcının hata yakalayabileceği beş nokta. Sıralama benim önerimdir.

Para transferi onay ekranı

Aynı transferin iki onay ekranı alt alta. Kullanıcı 1.500 TL yazmak isterken bir sıfır fazla yazdı.

Para gönderOnay

Alıcı IBANTR33 0006 1005 1978 6457 8413 26

AçıklamaKira

İşlem tutarı: 15.000,00 TL. İşlem ücreti uygulanabilir.

Onayla

Hatalı hali

• Ekranda yalnızca IBAN var. Kullanıcı 26 karakteri tek tek okumaz, parayı kime gönderdiğini görmez.
• Tutar küçük ve gri yazıyla bir cümlenin içinde. Fazladan yazılmış bir sıfır gözden kaçar.
• Buton "Onayla" diyor. Neyi onayladığınızı söylemiyor.
• Basınca para hemen gidiyor. Geri almanın bir yolu yok.

Para gönderOnay

Hesap sahibinin adı AY** YIL**** TR33 0006 1005 1978 6457 8413 26 Ad, alıcı bankanın kaydından gelir. Tanıdığınız kişi değilse göndermeyin.

Gönderilecek tutar 15.000,00 TL On beş bin Türk lirası İşlem ücreti: 0,00 TL

Bu kişiye daha önce en fazla 1.500 TL gönderdiniz. Tutarı bir kez daha kontrol edin.

15.000 TL gönder Tutarı düzelt

Doğru hali

• Alıcının adı maskeli ama tanınacak kadar açık. Kullanıcı kime gönderdiğini bir bakışta görür.
• Tutar büyük rakamla yazılıyor, altında bir de yazıyla tekrar ediliyor. Alışılmışın dışındaki tutar için ayrıca uyarı çıkıyor.
• Buton ne olacağını söylüyor: tutar ve eylem. Yanında tutarı düzeltme yolu var.
• Gönderim kısa bir süre bekletiliyor. Bu sürede "Geri al" ile işlem iptal edilebilir.

Ekranlar, banka ve kişi adları uydurmadır. Senaryo: kullanıcı 1.500 TL yazmak isterken bir sıfır fazla yazdı. Hatalı ve doğru hal arasında geçiş yapın, butonlara basın. Doğru halde gönderim 10 saniye bekletilir ve geri alınabilir.

Demodaki iki ekranda da IBAN ve tutar var. Fark, bu bilginin nerede ve hangi büyüklükte durduğunda. Hatalı ekranda tutar orada ama göze çarpmıyor.

Hata önleme

Hata mesajı yazmadan önce hatanın olmasını engellemeye bakın. Page Laubheimer, NN/g'deki yazısında bilinçsiz kaymaları, yani kullanıcının dalgınlıkla yaptığı hataları önlemenin yollarını sayar. Para ekranlarında karşılıkları şöyle:

• Kısıtlar. Kabul edilen değerler belliyse girişi sınırlayın. IBAN alanı "TR" ile başlar ve fazla karakter almaz. Bakiyeden yüksek tutar yazıldığında kullanıcı butona basmadan uyarılır.
• Esnek biçim. Kullanıcı IBAN'ı boşluklu ya da boşluksuz yapıştırabilir. Sistem bunu arkada temizler, kullanıcıya hata göstermez. Telefon numarası da aynı şekilde yazıldıkça biçimlenir.
• İyi varsayılanlar. Son alıcılar listenin başında durur. Kullanıcı aynı IBAN'ı her ay yeniden yazmaz.
• Öneriler. Kayıtlı kişiler yazarken önerilir. Kullanıcı hatırlamak yerine tanır.

Bir de çift gönderim sorunu var: ağ yavaşsa kullanıcı "Gönder"e ikinci kez basar. Buton ilk dokunuştan sonra hemen "Gönderiliyor" durumuna geçmeli ve ikinci dokunuşu almamalıdır. Aynı işlem hiçbir koşulda iki kez gitmemelidir.

Formların geri kalanı için form tasarımı sayfasındaki kurallar burada da geçerlidir. Etiket alanın üstünde durur, hata alanın hemen altında çıkar ve ne yapılacağını söyler.

Bildirim

Fintech'te işlem bildirimi, işlemin kendisine dahildir. Hesaptan para çıktığında kullanıcı bunu uygulamayı açmadan öğrenmelidir. Kendisinin yapmadığı bir işlemi ilk bildirimden fark eden kullanıcı, kartını hemen kapatabilir.

İyi bir işlem bildirimi için kontrol listem şu:

• Tutar ve para birimi.
• Karşı taraf: alıcının ya da iş yerinin tanınır adı.
• Durum: gönderildi, bekliyor ya da reddedildi.
• Kullanıcı işlemi tanımıyorsa ne yapacağı ve bunun tek dokunuşla nasıl yapılacağı.

İşlem bildirimlerini kampanya bildirimleriyle aynı kanala koymak bir hatadır. Kullanıcı kampanyalardan kurtulmak için tüm bildirimleri kapatabilir, sonra da kartından çekilen parayı geç fark eder. Ayarlarda bu iki tür ayrı ayrı kapatılabilmelidir.

Bildirim ile uygulamanın içi aynı şeyi söylemelidir. Bildirimde "gönderildi", işlem geçmişinde "bekliyor" yazıyorsa kullanıcı hangisine inanacağını bilemez.

Erişilebilirlik

Gözü az gören ya da ekran okuyucu kullanan biri de faturasını öder. Erişilebilir olmayan bir finans uygulaması bu kişiyi yardım istemeye iter. Para işinde yardım istemek, bazen şifreyi başkasıyla paylaşmak demektir.

Yukarıda andığım WCAG 2.2 maddelerini tek tabloda topladım.

Madde	Seviye	Fintech'te karşılığı
3.3.4 Hata önleme (yasal, finansal, veri)	AA	Transfer geri alınabilir, kontrol edilir ya da gönderimden önce gözden geçirilir.
3.3.8 Erişilebilir kimlik doğrulama	AA	SMS kodu yapıştırılabilir, şifre yöneticisi çalışır.
2.2.1 Ayarlanabilir süre	A	Oturum kapanmadan uyarı verilir, süre basit bir hareketle uzatılabilir.
4.1.3 Durum mesajları	AA	"Gönderildi" mesajı odak taşınmadan ekran okuyucuya iletilir.

Bu dört madde yalnızca bir başlangıç. Kontrast, dokunma hedefi ve klavye gibi temel ölçütleri WCAG rehberinde anlattım.

Demodaki geri sayımı tasarlarken 4.1.3'ü düşündüm. Süre ekranda yazıyla duruyor ve başlangıçta ekran okuyucuya bir kez duyuruluyor. Her saniye duyurulsaydı kullanıcı başka hiçbir şey duyamazdı.

Benim notum

Fintech ürünlerinde sık gördüğüm bir sorun şu: güvenliğin yükünü kullanıcı taşıyor. Yapıştırılamayan doğrulama kodları ya da nedenini söylemeyen "işlem reddedildi" mesajları buna örnek. Ekip bunları güvenlik diye savunur, kullanıcı ise engel olarak yaşar.

Benim kuralım şu: her güvenlik adımı kullanıcıya neden orada olduğunu söylemeli. "Bu tutar alışılmışın üstünde, o yüzden bir kez daha soruyoruz" diyen bir ekrana kullanıcı kızmaz. Gerekçesiz engele kızar.

İkinci kuralım: onay ekranına diğer ekranlardan daha çok vakit ayırırım. Kullanıcı o ekranda birkaç saniye kalır ama en pahalı hatalar orada olur. Bir fintech ürününe uçtan uca audit yaptığımda transfer onayını her zaman ayrıca, gerçek tutarlarla denerim.