Uygulama Arayüzünde Sık Tekrar Eden Tasarım Hataları

Arayüz hatalarının çoğu yaratıcılık eksikliğinden değil, kullanıcının zaten bildiği bir kalıbı gereksiz yere bozmaktan doğuyor. Aşağıdaki maddeler sık tekrar eden bozmalar ve her birinin karşısında yapılacak somut iş var. Bir de listenin kendi içinde çelişen bir maddesi var, orayı ayrıca ele alıyorum.

Kontrolü değiştirmeyin, görünürlüğünü değiştirin

Buton, onay kutusu, açılır liste. Bunların davranışını yeniden tasarlamanın getirisi neredeyse hiç yok, maliyeti ise her yeni kullanıcıda tekrarlanan bir öğrenme yükü. Sorun genelde kontrolün kendisinde değil, fark edilmemesinde olur. Kontrastı, boyutu, konumu değiştirin; tıklama davranışını değil.

Bağlantı gibi görünen ama bağlantı olmayan öğe bu kuralın en pahalı ihlali. Altı çizili mavi metin gördüğünde kullanıcı tıklar, tıklayınca hiçbir şey olmazsa arayüzün bozuk olduğunu düşünür.

Geri bildirimin bir süresi vardır

Geri bildirim eksikliği tek bir hata değil, üç ayrı eşiğe göre üç ayrı karar. Jakob Nielsen'in yıllardır tekrarladığı sınırlar hâlâ geçerli:

• 0,1 saniyeye kadar: kullanıcı doğrudan tepki hisseder, ek gösterge gerekmez.
• 1 saniyeye kadar: akış korunur, spinner koymak durumu iyileştirmez, sadece gözü rahatsız eder.
• 10 saniyeden uzun: kullanıcı başka işe geçer. Burada ilerleme yüzdesi ve tahmini süre şart.

Bu eşikler ölçülebilir. Ağ isteğinin ne kadar sürdüğünü tahmin etmeyin, kaydedin. Yavaş bağlantıda 1 saniye altı diye tasarladığınız işlem sahada 4 saniye sürüyorsa, geri bildirimi olmayan bir ekranınız var demektir.

Hata mesajı iki şeyi söylemek zorunda

Ne oldu ve şimdi ne yapılacak. İkincisi eksikse mesaj bir bilgilendirme değil, sadece bir suçlama olur. "Geçersiz giriş" kullanıcıya hiçbir şey vermez; "Telefon numarası 10 haneli olmalı, başında 0 olmadan yazın" yazdığınız satır sayısını değiştirmez ama destek yükünü değiştirir.

Hata mesajını hatalı alanın yanında gösterin. Formun üstünde toplanmış hata listesi, uzun formlarda kullanıcıyı ekranda oraya buraya yolluyor.

Kullanıcının emeğine dokunmayın

Aynı veriyi ikinci kez sormak, kullanıcı açısından sizin veri modelinizin dağınıklığını onun doldurması demek. Kayıt sırasında alınan bilgiyi sipariş adımında yeniden istemek bunun klasik hali. Verinin nerede durduğu kullanıcının problemi değil.

Varsayılan değerler de aynı hesabın parçası. En sık seçilen değeri seçili getirmek, yeni kullanıcıyı yönlendirir, deneyimliyi hızlandırır. Riski düşük, kazancı her oturumda tekrarlanıyor.

Reset butonu ve listenin kendi çelişkisi

Bu tür listelerde iki madde çoğunlukla yan yana durur: "standart kontrollere sadık kal" ve "formlarda reset butonu kullanma". Reset, HTML'in ilk günlerinden beri gelen standart bir kontrol. Yani iki tavsiye birbirini yalanlıyor.

Kuralın doğru hali şu: bir kontrol, kullanıcının beklediği sonucu ürettiği sürece standarttır. Reset butonu gönder butonunun yanında durur, aynı boyuttadır, yanlışlıkla basıldığında da geri alınamaz. Standart olması onu iyi yapmıyor, sadece eski yapıyor. Bir kayıt formunda reset butonunu kaldırdığımızda "yazdıklarım silindi" şikâyeti tek seferde kesilmişti.

Yıkıcı işlemler için genel kural: ya onay isteyin, ya geri alma verin. İkincisi neredeyse her zaman daha iyi, çünkü onay diyaloğu birkaç tekrardan sonra otomatik tıklanan bir engele dönüşüyor.

Dokunma alanını ölçüyle belirleyin

Affordans tartışması çoğu zaman görsellikte kalıyor ama mobilde işin ölçü tarafı var. Apple'ın insan arayüzü kılavuzu 44x44 pt, Android tarafı 48x48 dp öneriyor. Görsel öğe daha küçük olabilir, dokunulabilir alanın küçük olması gerekmiyor: butonun etrafına görünmez dolgu vermek çoğu durumda üç satırlık iş.

Bu ölçü motor kas kontrolü sınırlı kullanıcılar için isteğe bağlı bir iyileştirme değil, kullanılabilirliğin ön koşulu. Yan yana duran iki küçük ikon, titremesi olan bir kullanıcıda yanlış işlem demek.

Veriyi neden istediğinizi yazın

Telefon numarası isteyen bir alanın altına tek satır açıklama koymak dönüşümü artırır, çünkü kullanıcı en çok bilmediği şeyden çekinir. Kargo firması arayacaksa onu yazın. Pazarlama için istiyorsanız da onu yazın, kullanıcı zaten tahmin ediyor.

Gelişmiş ayarları da aynı mantıkla saklayın. İhtiyacı olan kullanıcı açar, olmayan hiç görmez, ikisi de kaybetmez.