UX Tutarlılığı: Belgede Değil, Bileşende Kurulur
Tutarlılık, arayüzde aynı şeyin her yerde aynı biçimde çalışması demek. Kulağa basit geliyor, ama ekip büyüdükçe kendiliğinden bozulur; çünkü kimse bilerek tutarsızlık üretmez, herkes kendi ekranında yerel olarak doğru kararı verir. Asıl soru, o yerel doğruların tek bir sistemde toplanıp toplanmadığı.
Tutarlılık derken tam olarak ne aynı kalıyor
Konuya yeni girenler tutarlılığı çoğunlukla görsel bir mesele sanır. Aslında üç ayrı katman var ve bunlar birbirinden bağımsız bozulabilir.
Görsel katman en görünür olanı: renkler, yazı tipi ölçeği, boşluklar, ikon dili. Bozulduğunda hemen fark edilir, düzeltmesi de en kolayıdır.
Etkileşim katmanı daha derinde. Bir işlemi onaylamak bir ekranda modal açıyorsa, diğerinde sayfayı değiştirip geri dönmemeliydi. Kullanıcı bir kez öğrendiği hareketi ikinci ekranda tekrar öğrenmek zorunda kalıyorsa etkileşim tutarlılığı yok demektir.
Kavramsal katman ise en çok atlanan yer: aynı nesnenin farklı ekranlarda farklı adla anılması. Bir yerde “üye”, bir yerde “kullanıcı”, faturada “hesap sahibi”. Üçü de aynı kayda işaret ediyorsa kullanıcı bunların farklı şeyler olduğunu düşünür ve destek kutusuna yazar. Bu katman veritabanı isimlendirmesinden arayüz metnine kadar uzandığı için, düzeltilmesi de en pahalı olandır.
Prensip, bir şeyi kaybettiriyorsa prensiptir
Çoğu ekip tasarım prensiplerini “sadelik, erişilebilirlik, hız” gibi bir listeyle yazar ve bu liste hiçbir tartışmayı çözmez. Sebebi basit: kimse toplantıda karmaşıklığı savunmuyor. Herkesin baştan katıldığı bir cümle, iki iyi seçenek arasında kalındığında taraf tutmaz.
İşe yarayan prensip bir bedeli açıkça kabul eder. “Yeni kullanıcının ilk beş dakikasını hızlandırmak için uzman kullanıcıyı bir tık yavaşlatırız” gibi. Böyle yazıldığında tartışma biter, çünkü karşı tarafın itirazı da net bir yere oturur: bu ürün uzman kullanıcıyla mı yaşıyor, yeni kullanıcıyla mı? Prensip listesini yazdıktan sonra tek tek sorun, hangisinin tersini savunan makul bir insan olabilir. Tersi savunulamıyorsa o satır prensip değil, süs.
Stil rehberi çürür, bileşen çürümez
Stil rehberleri iyi niyetle hazırlanır ve genellikle altı ay içinde gerçeklikle bağını koparır. Nedeni disiplinsizlik değil, geri bildirim eksikliği: rehbere aykırı bir buton yazdığınızda hiçbir şey kırılmaz, hiçbir test kırmızıya dönmez, kimse haberdar olmaz. Kuralın tek yaptırımı insan hafızasıysa unutulur.
Tutarlılığı kalıcı kılan yer koddur. Buton tek bir bileşende tanımlıysa, renk ve boşluk değerleri değişkenlerden geliyorsa, tutarlılık bir tercihe değil varsayılana dönüşür. Tasarımcının rehberi açıp bakmasına gerek kalmaz, çünkü tutarsız olanı üretmek fazladan emek ister. Bunu üç seviyede kurabilirsiniz: renk ve ölçek değerleri için tokenlar, tekrar eden parçalar için ortak bileşenler, doğrudan renk kodu yazılmasını engelleyen bir lint kuralı. Üçüncüsü olmadan ilk ikisi zamanla sızdırır (rehberi PDF olarak dağıtıp iş bitti sanmak, gördüğüm en yaygın hata).
Ölçmek: A/B testi çoğu site için yanlış araç
Kararları veriye bağlamak doğru bir hedef, ama önerilen araç genelde ölçeğe uymuyor. A/B testi istatistiksel bir yöntem ve gerektirdiği trafik, aradığınız farkın küçüklüğüyle hızla büyür. Dönüşüm oranınız %3 civarındaysa ve bunda göreli %10'luk bir iyileşme arıyorsanız, anlamlı sonuç için varyant başına on binlerce ziyaret gerekir. Haftada birkaç bin ziyaretçi alan bir site bu testi bitiremez; bitirdiğini sandığı yerde gürültüyü sonuç diye okur.
Küçük ölçekte işe yarayan iki şey var. Birincisi moderasyonlu kullanılabilirlik testi: beş kişiyle yapılan bir oturum, ciddi engellerin büyük kısmını yakalar ve bunun için trafik değil, sadece beş randevu gerekir. İkincisi hunideki tek bir adımı ölçmek. Hangi ekranda kaç kişinin düştüğünü bilmek, hangi butonun daha çok tıklandığını bilmekten çok daha fazlasını söyler ve kurulumu bir olay kaydından ibarettir.
Nereden başlamalı
Sıfırdan bir tasarım sistemi kurmaya girişmeyin. Önce envanter çıkarın: ürününüzdeki kaç farklı buton, kaç farklı boş durum ekranı, kaç farklı tarih biçimi var? Bu sayı genellikle tahmin edilenin iki katı çıkar ve hangi alanın acil olduğunu kendisi söyler.
Sonra sırayla: kavramsal isimlendirmeyi birleştirin, en çok tekrar eden üç parçayı ortak bileşene taşıyın, en son görsel değerleri tokenlara alın. Bu sıra tesadüfi değil; isimlendirme düzeltmesi metni de veriyi de etkilediği için ne kadar geç kalırsanız o kadar pahalıya mal olur, görsel tokenlar ise en son adımda bile ucuz kalır.