Mobil Uygulamada Kullanıcı Deneyimi: Beş Karar ve Bedelleri
UX tavsiyelerinin çoğu doğru olduğu için değil, kimse itiraz etmediği için tekrarlanıyor. Sade tut, kullanıcıyı dinle, bildirim yağdırma. Hepsi makul görünüyor; ama her biri bir şeyden vazgeçmeyi gerektiriyor ve tavsiyeyi veren genelde tam o kısmı atlıyor.
Özellik turu bir semptomdur
Uzun açılış turlarının atlandığı doğru. Ama "turu kaldır, sade ol" cevabı hiçbir şeyi çözmüyor, çünkü tur bir sebeple oraya konmuş: uygulamanın asıl işi ilk ekranda görünmüyor.
Bunun basit bir testi var. Uygulamayı sıfırdan aç, hiçbir açıklama okumadan ana eylemi tamamlamayı dene. Tamamlanamıyorsa sorun turda değil, navigasyonda. Bir de şu var: "tur yapma" ile "özellikleri kullanıcı ilerledikçe aç" aynı anda söylendiğinde çelişki çıkıyor, ikincisi de öğretmek. Farkı zamanlama belirliyor, varlığı değil.
Destek kutusu temsili bir örneklem değil
Destek talebi yazan kullanıcı, uygulamayı hâlâ umursayan kullanıcıdır. Vazgeçen kişi mesaj yazmaz, siler ve gider. Yani elindeki geri bildirim yığını, kalanların sesi; gidenler hakkında tek kelime içermiyor.
Bu yüzden "kullanıcıyı dinleyin" tavsiyesi tek başına yanıltıcı. Dinlenecek asıl şey davranış: hangi ekranda akış kesiliyor, kaçıncı adımda oran düşüyor, ilk oturumla ikinci oturum arasında kaç kişi kayboluyor. Uygulama içi mikro anketler işe yarar, ama onların da cevap oranı kendi içinde taraflıdır; ankete cevap veren kişi zaten ortalamanın üstünde ilgili olandır.
Yüksek çözünürlük bedava değil
Her ikonu 1x, 2x, 3x olarak paketlemek uygulama boyutunu büyütür ve ilk indirmeyi yavaşlatır. Raster yerine vektör kullanılabilen her yerde vektör kullanmak bu maliyeti sıfıra yakın düşürür.
Ekran teknolojisinden faydalanmanın görsel kaliteden daha somut bir tarafı da var: dokunma hedefleri. iOS tarafında 44x44 pt, Android tarafında 48x48 dp altına inen bir buton, ekran ne kadar keskin olursa olsun ıskalanır. Kaydırma ve sürükleme jestleri eklerken de aynı jesti sistemin kendi kenar hareketleriyle çakıştırmamak gerekiyor.
Kaydı ertelemenin görünmeyen maliyeti
Misafir girişi terk oranını düşürür, burada tartışacak bir şey yok. Tartışılması gereken, sonrasında ne olacağı. Kullanıcı misafirken veri üretiyorsa, kayıt anında o veriyi hesabına taşımanız gerekir; bunu baştan planlamazsanız elinizde sahipsiz kayıtlar kalır.
Pratikte ihtiyacınız olan şey, cihazda üretilen anonim bir kimlik ve kayıt anında sunucu tarafında çalışan bir birleştirme adımı. Kenar durumu da unutulmasın: aynı kişi iki cihazda misafir olarak veri biriktirmişse, ikinci birleştirmede hangi kaydın kazanacağına dair bir kural yazmak zorundasınız. Bu kuralı sonradan eklemek, veritabanında çoktan oluşmuş çakışmaları temizlemek anlamına geliyor.
Bildirim izni tek atışlıktır
"Bildirimleri azaltın" tavsiyesinden önce gelen daha keskin bir kısıt var: izin isteme hakkınız bir kere. iOS'ta kullanıcı reddettiğinde sistem sorusunu tekrar gösteremezsiniz, kişiyi Ayarlar'a yönlendirmek zorunda kalırsınız. Android 13 ve sonrasında da bildirim ayrı bir çalışma zamanı izni.
Bu yüzden ilk açılışta sorulan izin, uygulamanın ne işe yaradığı henüz anlaşılmadan harcanmış olur (uygulamaların yarısında bunun bilinçli bir karar olduğunu sanmıyorum). Doğru an, bildirimin karşılığının kendiliğinden belli olduğu andır: takip edilen bir sipariş, kurulan bir hatırlatma, beklenen bir cevap.
Performans, arayüzden önce gelir
Yavaş açılan bir uygulamada hiçbir arayüz kararı kendini kurtaramaz. Ölçerken ortalamaya bakmayın; ortalama soğuk açılış süresi iyi görünürken kullanıcıların yüzde beşi saniyelerce bekliyor olabilir. p95 değeri gerçeği daha dürüst anlatır.
Algılanan hız da ayrı bir başlık. Veriyi beklerken boş ekran yerine iskelet yerleşim göstermek, ölçülen süreyi değiştirmez ama bekleme hissini kısaltır.
Hangisi önce
Bu beş başlık eşit ağırlıkta değil. Sıralama yapmak gerekirse önce açılış performansı ve kayıt akışı gelir, çünkü ikisi de kullanıcıyı ürünü hiç görmeden kaybettirir. Görsel kalite ve jest desteği ise ancak kullanıcı kalmayı seçtikten sonra fark yaratır.