Mobil bankacılık şikâyetlerinde UX payı

Bir şikâyeti nasıl okuyorum

Kullanıcı yorum yazarken teknik sorunla tasarım sorununu ayırmaz. Onun için uygulama ya işini görür ya görmez. “Berbat uygulama” yazan biri sunucu kesintisini de anlatıyor olabilir, anlamadığı bir hata mesajını da.

Bu yüzden şikâyetleri okurken kendime tek bir soru sorarım: Sistem gerçekten bozuldu mu, yoksa çalıştı da kullanıcı bunu mu anlayamadı? İkinci durumda sorun arayüzdedir ve çözümü de oradadır.

Para gönderme işlemi arka planda başarıyla tamamlanmış olabilir. Ekran dönüp durduysa ve sonuç yazmadıysa, kullanıcı için o para kaybolmuştur. Ortada teknik bir arıza yok, sorun kullanılabilirlik tarafında.

Şikâyet türünden ilkeye

Mobil bankacılık sorunlarını sınıflarken Nielsen'in 10 kullanılabilirlik ilkesini kullanırım. Jakob Nielsen ilkeleri 1990'da Rolf Molich ile geliştirdi, 1994'te bugünkü haline getirdi. Ölçüt olarak eskimediler, çünkü insanların bir ekranı nasıl okuduğu çok değişmedi.

Aşağıda sık duyulan şikâyet türlerini topladım. Her birinin yanında ilgili ilke ve benim önereceğim tipik düzeltme var.

Şikâyet → ilke

Giriş yapamıyorum

“Şifremi doğru giriyorum, uygulama yine de içeri almıyor.”

İlgili ilke İlke 9: Kullanıcının hataları tanımasına, teşhis etmesine ve düzeltmesine yardım edin.

Neden: Ekran yalnızca “Giriş başarısız” diyor. Kullanıcı şifre mi yanlış, hesap mı kilitli, yoksa sistem mi kapalı bilemiyor.

Tipik düzeltme: Hatanın nedenini ve sonraki adımı yazın. Kalan deneme hakkını gösterin. Şifre yöneticisine ve yapıştırmaya izin verin. WCAG 2.2'nin 3.3.8 maddesi de girişte şifre hatırlamak gibi bir bilişsel test varsa alternatif ya da yardımcı bir mekanizma ister.

Oturum sürekli kapanıyor

“Fatura numarasını bulmaya gittim, döndüğümde her şey silinmişti.”

İlgili ilke İlke 1: Sistem durumunun görünürlüğü.

Neden: Oturum haber vermeden kapanıyor ve yazılanlar kayboluyor. Kullanıcı neden atıldığını ve ne kadar süresi kaldığını görmüyor.

Tipik düzeltme: Süre dolmadan uyarın ve tek dokunuşla uzatma imkânı verin. WCAG 2.2'nin 2.2.1 maddesi bunu seçeneklerden biri sayar: kullanıcı en az 20 saniye içinde basit bir hareketle süreyi uzatabilir. Geri dönüldüğünde formdaki bilgileri koruyun.

Güncellemeden sonra kayboldum

“Yeni sürümde para transferi nereye gitti?”

İlgili ilke İlke 4: Tutarlılık ve standartlar.

Neden: Kullanıcının kafasındaki harita bir gecede değişmiş. Her gün yaptığı işin yeri artık başka bir menünün altında.

Tipik düzeltme: Sık kullanılan işlerin yerini değiştirmeden önce iki kez düşünün. Değiştiyse eski yerden yeni yere bir yönlendirme bırakın. Uygulama içi aramada eski adlarla da sonuç çıksın.

Para gitti mi, bilmiyorum

“Gönder’e bastım, ekran döndü durdu. Tekrar basayım mı?”

İlgili ilke İlke 1: Sistem durumunun görünürlüğü. İlke 5: Hata önleme.

Neden: Ekran işlemin hangi aşamada olduğunu söylemiyor. Kullanıcı ikinci kez basıp aynı parayı iki kez göndermekten korkuyor.

Tipik düzeltme: İşlem durumu için ayrı bir ekran gösterin: alındı, işleniyor, tamamlandı. Dekontu aynı yerde verin. Sonuç belli olmadan aynı işlemin ikinci kez gönderilmesini engelleyin.

Hata mesajı anlaşılmıyor

“İşleminiz gerçekleştirilemedi. Hata kodu: 5021.”

İlgili ilke İlke 9 ve İlke 2: Sistem ile gerçek dünya arasında uyum.

Neden: Mesaj sistemin dilini konuşuyor. Kullanıcı ne olduğunu ve şimdi ne yapacağını öğrenemiyor, bu yüzden çağrı merkezini arıyor.

Tipik düzeltme: Mesajı hatalı alanın yanına koyun. Ne olduğunu ve nasıl düzeleceğini düz Türkçeyle yazın. Kullanıcının yazdıklarını silmeyin. Kodu yalnızca destek için gerekiyorsa küçük olarak gösterin.

Uygulama çok karışık

“Basit bir fatura ödemek için beş ekran geziyorum.”

İlgili ilke İlke 8: Estetik ve sade tasarım.

Neden: Ana ekranda kampanyalar ve ikincil işler, kullanıcının her gün yaptığı işle yarışıyor.

Tipik düzeltme: Ana ekranda en sık yapılan birkaç işi öne çıkarın. Kampanyayı ana işin önüne koymayın. Nadir kullanılan ayarları bir alt menüye taşıyın.

Uygulama açılmıyor, çöküyor

“Güncellemeden sonra uygulama açılır açılmaz kapanıyor.”

İlgili ilke Önce mühendislik sorunu. UX tarafı: İlke 1 ve İlke 9.

Neden: Çökmenin kendisi tasarımla çözülmez. Ama kullanıcıya ne olduğunu söylemek ve onu boşlukta bırakmamak tasarımın işi.

Tipik düzeltme: Hatayı düzeltecek olan geliştirme ekibidir. Arayüz tarafında bilinen bir kesintiyi uygulamanın ilk ekranında duyurun. Yeniden açılınca kullanıcıyı kaldığı yere götürün.

Şikâyet cümleleri örnektir, belirli bir bankanın yorumlarından alınmadı. Bir tür seçin, kart o türe uyan Nielsen ilkesini ve tipik düzeltmeyi göstersin. JavaScript kapalıysa bütün kartlar alt alta görünür.

Listeye bakınca bir şey dikkat çekiyor. Bu listedeki türlerin çoğu iki ilkeye dayanıyor: sistem durumunun görünürlüğü ve hatalardan kurtulmaya yardım. Kullanıcı önce ne olduğunu bilmek istiyor. Bir şey ters gidince de ne yapacağını.

Bankada neden daha çok can yakıyor

Bir oyun uygulamasında belirsiz bir ekran sinir bozar. Bankada ise korku yaratır. Kullanıcı kendi parasıyla ilgili bir işlemin sonucunu bilmiyorsa, aklına önce en kötü ihtimal gelir.

Bu korkunun bir de maliyeti var. Ekranda cevap bulamayan kullanıcı çağrı merkezini arar ya da şubeye gider. Uygulamanın yapması gereken işi bir insan yapmak zorunda kalır.

Güven de buradan zedelenir. Kullanıcı bir kez “para gitti mi” diye panik yaşadıysa, bir sonraki işlemde aynı ekrana daha temkinli yaklaşır. Bazen de işlemi uygulamada yapmaktan vazgeçer.

Hata mesajları ayrı bir dert

Banka uygulamalarında en çok takıldığım yer hata mesajlarıdır. Nielsen Norman Group'tan Tim Neusesser ve Evan Sunwall'ın 2023 tarihli rehberi burada net kurallar verir.

Mesaj hatanın kaynağına yakın durmalı ve yalnızca renge dayanmamalı. Ne olduğunu ve nasıl düzeleceğini söylemeli. Kullanıcı baştan başlamak yerine kendi girdiğini düzelterek devam edebilmeli.

Aynı rehber, kullanıcıyı suçlayan “geçersiz” ve “hatalı” gibi kelimelerden uzak durmayı önerir. Teknik kodların da tanı için gerekmedikçe gizlenmesini ister. “Hata kodu: 5021” bu kuralların neredeyse hepsini çiğner.

Her şikâyet UX değildir

Her mobil bankacılık şikâyeti tasarımla çözülmez. Sunucu kesintisi ya da güncellemeyle gelen bir çökme önce mühendislik sorunudur.

Güvenlik için konmuş adımlar da öyle. Ek bir doğrulama adımını sırf kullanıcı sıkılıyor diye kaldırmam. Ama o adımın nasıl anlatıldığı ve hata verince ne dediği tasarımın işidir.

Erişilebilirlik tarafında WCAG 2.2 iyi bir dayanak sunar. Örneğin 2.2.1 maddesi, süre sınırı olan içerikte kullanıcıya uyarı ve uzatma gibi seçenekler ister.

3.3.7 maddesi ise aynı süreçte daha önce girilen bir bilgi yeniden gerekiyorsa otomatik doldurulmasını ya da seçilebilir olmasını ister. Ayrıntılar WCAG rehberinde.

Benim notum

Bir banka uygulamasına baktığımda ilk durduğum yer ana ekran değildir. Para gönderme akışının sonundaki ekrana bakarım. Kullanıcının en çok korktuğu an orasıdır ve şikâyetler de çoğu zaman oradan çıkar.

İkinci baktığım şey güncellemeler. Menüyü yeniden düzenlemek ekip için bir iyileştirmedir. Kullanıcı için ise ezberlediği yolun bir sabah kaybolmasıdır. Ben buna zihinsel modelin bozulması diyorum.

Şikâyet listeniz varsa bana en çok tekrar eden on yorumu göstermeniz yeter. Hangilerinin arayüzden geldiğini çoğu zaman ilk okumada ayırabilirim. Uygulamanın tamamına bakmak isterseniz UX Audit Pro on akışa kadar kapsıyor.