Mobil Arayüzde Geri Bildirim ve Bildirim Tasarımı
Kullanıcı ekrana dokunur ve bir şey bekler. O beklentiyi karşılamanın adı geri bildirimdir: dokunmanın algılandığını, işlemin başladığını, bittiğini ya da başarısız olduğunu anlatan her sinyal. Mobilde bu sinyaller masaüstündekinden daha kısa sürede ve daha küçük bir alanda verilmek zorunda, o yüzden tasarımı da daha katı kurallara bağlı.
Geri bildirim tek bir şey değil, iki ayrı soruya cevaptır
Bir arayüzde geri bildirim tasarlarken işe şu ayrımı yaparak başlamak gerekiyor. Kullanıcının zihninde sırayla iki soru var: dokunuşum kaydedildi mi ve işlem ne oldu. Bunlar aynı soru değil, aynı yöntemle de cevaplanmaz.
Birincisi algıyla ilgilidir. Butonun basılı hali, hafif bir titreşim, satırın rengi. Amaç kullanıcıyı bilgilendirmek değil, dokunuşun boşa gitmediğini göstermek. Bunu sunucuya sormaya gerek yok, tamamen istemci tarafında halledilir.
İkincisi sonuçla ilgilidir ve gerçekten beklemeyi gerektirir: kayıt gitti mi, dosya yüklendi mi, ödeme geçti mi. Bu ikisini karıştıran arayüzlerde şu tanıdık hata çıkar: kullanıcı butona basar, hiçbir şey olmaz, tekrar basar, iki kayıt oluşur.
"Anında geri bildirim" ile ilerleme göstergesi çelişmez
Mobil tasarım tavsiyelerinde sık tekrarlanan bir cümle var: geri bildirim milisaniyeler içinde gelmeli. Hemen ardından da ilerleme çubukları önerilir. İlk bakışta bu ikisi birbiriyle çelişiyor gibi durur, çünkü ilerleme çubuğu tam da işlemin milisaniyelerle bitmediği durumda vardır.
Çelişki, yukarıdaki ayrımı yapınca kayboluyor. Hızlı olması gereken şey işlem değil, işlemin başladığına dair sinyal. Arayüz yanıt süreleri için yıllardır kullanılan üç eşik burada işe yarar: yaklaşık 100 milisaniyeye kadar kullanıcı tepkiyi anlık algılar, bir saniyeye kadar düşünce akışı bölünmez, on saniyeden sonra dikkat başka yere kayar.
Pratikte kural şu: dokunuşun görsel karşılığı 100 milisaniyenin altında verilir. İşlem bir saniyeyi aşacaksa belirsiz bir dönen ikon yeterli. On saniyeyi aşacaksa kullanıcıya kalan miktarı gösteren bir şey borçlusunuz, yoksa uygulamanın kilitlendiğini düşünür. Yükleme süresini önceden bilmiyorsanız yüzde göstermeyin; yanlış yüzde, hiç yüzde göstermemekten daha çok güven kaybettirir.
Onay kutusu yerine geri alma
Yıkıcı işlemlerde kullanıcıyı iki kez uyarma tavsiyesi yaygın. Mantığı açık: silme geri dönüşü olmayan bir iş, o yüzden bir kez daha sorulsun. Sorun, bu mantığın kullanıcı alışkanlığını hesaba katmaması.
Aynı onay kutusunu günde beşinci kez gören kişi artık onu okumuyor. Kutu, silme akışının bir parçasına, yani ikinci bir tıklamaya dönüşüyor. Böylece koruma diye eklenen adım korumayı bırakıp sadece sürtünme haline geliyor. Onay kutusu, ancak nadiren karşılaşılan ve gerçekten telafisi olmayan işlemlerde işe yarar. Hesap kapatma, evet. Listeden bir satır silme, hayır.
Silme onayını ben genelde onay kutusuyla değil, birkaç saniyelik geri alma bandıyla çözerim: kayıt hemen listeden kalkar, altta "geri al" görünür, süre dolunca iş kesinleşir. Kullanıcı tarafında bu daha akıcı, ama bedava değil ve bedeli arayüzde değil veritabanında ödeniyor.
Geri alma, kaydın silinmiş görünüp aslında durması demek. Yani gerçek bir DELETE yerine işaretleme, ona bağlı sorguların hepsinde bu işareti dikkate alan bir filtre, bir de bu kayıtları gerçekten temizleyen bir görev. Tasarım tarafında bir bant, veri tarafında üç ayrı yerde değişiklik. Geri almayı tasarım kararı olarak önerirken bu maliyeti önceden söylemek gerekir, çünkü sonradan öğrenilirse ilk feda edilen şey oluyor.
Bildirim dozu tek bir düğmeyle sınanır
Geri bildirim kullanıcının kendi yaptığı işin karşılığıdır, bildirim ise uygulamanın kullanıcıyı kendi başlatmadığı bir şey için rahatsız etmesidir. İkisini aynı başlık altında toplamak, bildirimin bütçesinin çok daha dar olduğunu gizler.
Bütçeyi gösteren tek bir ölçü var: bildirimleri kapatma oranı. Tıklanma oranı yanıltıcıdır, çünkü kapatmayan ama artık okumayan kullanıcıyı da başarı sayar. Kapatma oranı ise geri dönüşsüzdür. Kullanıcı bir kez sistem ayarlarından bildirimlerinizi kapattığında, sonraki gerçekten gerekli bildirim de ona ulaşmaz.
Buradan çıkan pratik sıra şöyle işliyor:
- Bildirim izni ilk açılışta değil, kullanıcının o bildirimi isteyeceği bir işi yaptığı anda istenir. Sipariş verdikten sonra kargo bildirimi istemek makul, uygulamayı ilk açan kişiye sormak değil.
- Her bildirim türü ayrı ayrı kapatılabilir olmalı. Tek bir açma kapama düğmesi bırakırsanız, kullanıcı en gereksiz bildirimden kurtulmak için hepsini kapatır.
- Gönderdiğiniz her bildirimin tek bir aksiyonu olsun. Aksiyonu olmayan bildirim bilgilendirme değil, uygulama içi bir ekranda durması gereken bir bilgidir.
Dengeyi testle bulmak, ama neyi ölçtüğünü bilerek
Aşırı bildirim kullanıcıyı boğar, eksik bildirim yönsüz bırakır. Bu dengenin nerede olduğu ürüne göre değişir ve masa başında bulunmaz. A/B testi burada işe yarar, yeter ki başarı ölçütü doğru seçilsin.
Bir bildirim varyantını tıklanma oranıyla değerlendirirseniz, kazanan hep daha agresif olan çıkar. Kısa vadede haklıdır da. Aynı testi kapatma oranı ve bir sonraki haftanın geri dönüş oranıyla birlikte okuduğunuzda tablo çoğu zaman tersine döner. Tek bir metriğe bakan bildirim testleri, ürünü fark edilmeden bildirimsiz bir ürüne dönüştürür.
Kaynaklar