Projelerde İşe Yarayan Beş UX Kararı
Bir projede kullanıcı deneyimini belirleyen şey uzun bir ilkeler listesi değil, birkaç somut karardır: neyi ölçüyorsunuz, arayüzden neyi çıkarıyorsunuz, testi hangi aşamada yapıyorsunuz. Aşağıda bu kararların işe yarayan hallerini, çoğu projede boşa giden hallerinden ayırdım. A/B testi bölümünde bir hesap var; çoğu ekibin o testi anlamlı kılacak trafiği yok.
Tasarıma başlamadan önce problemi tek cümleye indirin
Yeni projede refleks, hemen ekran çizmek ya da kod yazmaktır. Bu refleks pahalıdır. Ekibin tamamının aynı cümleyi kurabildiği bir hedef yoksa, ilerleyen haftalarda her tartışma baştan başlar ve iterasyonlar birikir.
Kullanıcı ihtiyacını netleştirmek de aynı işi görür: ne yapacağınızı değil, neden yapacağınızı yazıya döker. Bu ikisi yazılı değilse yolculuk haritası çıkarmanın da faydası yok, çünkü haritayı neye göre okuyacağınızı bilemezsiniz.
Yolculuk haritası, güzel şema değil
Kullanıcının ürünle karşılaştığı ilk andan hedefine ulaştığı ana kadar geçen adımları sırayla yazın. Asıl değeri başarı senaryosunda değil, arada kalan yerlerde: bekleme ekranı, boş sonuç sayfası, hata mesajı, e-postayı bekleyen doğrulama adımı. Ekipler bu adımları tasarlamaz, çünkü mutlu yolu tasarlarken hiç görmezler.
Yolculuk haritasını genelde tek bir sayfada, adım başına tek satır olacak şekilde çıkarırım; araç seçimiyle uğraşınca ortaya harita değil sunum çıkıyor.
A/B testi çoğu sitede işe yaramaz
“Her değişikliği test edin” tavsiyesi kulağa doğru gelir ama örneklem maliyetini atlar. Dönüşüm oranını %2'den %2,4'e çıkaran bir değişikliği %95 güven ve %80 güçle yakalamak için gereken ziyaretçi sayısı kabaca 16 × p(1-p) / δ² ile bulunur. p=0,02 ve δ=0,004 koyunca varyant başına yaklaşık 20.000 ziyaretçi çıkar, yani toplam 40.000.
Günde 200 ziyaretçi alan bir sitede bu test yüzlerce gün sürer. O süre boyunca sayfa da, sezon da, trafik kaynağı da değişir. Yani testin sonucu geldiğinde ölçtüğü şey artık ortada yoktur.
Bu trafik yoksa doğru araç kullanılabilirlik testidir. Beş ile sekiz kişiyle, ekranı paylaşarak, tek bir görev vererek yapılır ve buton renginden çok daha büyük sorunları ilk iki katılımcıda ortaya çıkarır. A/B testini yüksek trafikli, dar kapsamlı sorulara saklayın.
Arayüzden çıkarmak, eklemekten zordur
Proje büyüdükçe özellik eklemek kolaylaşır, çünkü her ekleme tek başına savunulabilir. Toplamı savunulamaz. Ana menüye giren her öğe, oradaki diğer her öğenin görünürlüğünü azaltır.
Basit bir kural işe yarar: bir özelliğin ana arayüzde yer tutabilmesi için kullanım verisinde görünmesi gerekir. Analytics'te ayda birkaç kez tıklanan bir menü öğesi silinmek zorunda değil, ama ana menüden çıkıp ayarların ya da ilgili sayfanın içine taşınabilir. Kullanan bulur, kullanmayanın önünden çekilir.
Etiketleri siz değil, kullanıcı seçsin
Gezinme yapısında yaratıcılık zarar verir. “Ayarlar”, “Profil”, “Siparişlerim” gibi tanıdık etiketler kullanıcının zihnindeki modelle eşleştiği için hiç düşündürmez. Marka diline uygun bulunmuş özgün isimler ise her ziyarette küçük bir çeviri işi yaratır.
Görsel hiyerarşi bu yapının okunmasını sağlar. Başlık boyutu, kontrast ve boşluk, hangisinin önce okunacağını söyler. Her şeyin aynı puntoda ve aynı ağırlıkta olduğu bir sayfada hiçbir şey öne çıkmaz.
Mobilde hamburger menü tek başına yeterli değil. En sık kullanılan üç dört eylemi alt çubukta, başparmağın ulaşabileceği yerde tutmak, o eylemlere erişim süresini bir dokunuş seviyesine indirir.
Erişilebilirlik ve formlar aynı işin iki parçası
Erişilebilirlik ayrı bir proje değil, kod düzeyinde birkaç alışkanlıktır. Görsellerde anlamlı alt metin, form alanlarında label ile for eşleşmesi, klavyeyle gezilebilen bir sekme sırası, yeterli kontrast oranı. Bunların hepsi ekran okuyucu kullanmayan ziyaretçi için de arayüzü düzeltir, çünkü hepsi yapının tutarlı olmasını zorunlu kılar.
Formlar terk edilme noktasıdır. Uzun formu adımlara bölmek işe yarar. Hata mesajını sayfanın tepesine toplamak yerine ilgili alanın yanına yazmak da öyle. Zorunlu alanı yalnızca yıldızla işaretlemeyin; kullanıcı yıldızın ne anlama geldiğini formun başındaki açıklamayı okumadan bilmez ve o açıklamayı okumaz.
Performans bir tasarım kararıdır
Yavaş açılan sayfa, tasarımı ne olursa olsun kötü deneyimdir. Kullanıcı sayfanın tamamen yüklenmesini beklemez, ilk birkaç saniyede işine yarayan bir şey görmek ister.
Buradaki en büyük kalem genelde görsellerdir. Sunucudan 2000 piksel genişliğinde gönderilip tarayıcıda 400 piksele sığdırılan bir fotoğraf, tasarımda görünmeyen ama faturası kullanıcıya çıkan bir hatadır. Görselleri kullanılacak boyutta üretin, güncel formatlarda sunun, ekrana girmeyenleri geciktirin. Bu üçü, çoğu sayfada tema değiştirmekten daha fazla kazandırır.
Kaynaklar