İşe Yarayan Beş UX Pratiği: Testten Eskize
UX pratikleri listesi okumak kolay, sırayı doğru kurmak zor. En sık görülen üç hata birbirini besliyor: hangi soruyu sorduğunu bilmeden test aracı seçmek, analitiğe sormadığı sorunun cevabını yükletmek, eskiz aşamasını atlayıp doğrudan dijital prototipe geçmek. Aşağıdaki beş pratik bu sırayı düzeltiyor.
Aracı değil, soruyu seçin
Test aracı seçimi teknik bir karar değil. Önce cevabını istediğiniz soruyu yazın, araç kendiliğinden belirir. "İki tasarımdan hangisi daha çok satıyor?" sayısal bir sorudur, A/B testine gider. "Kullanıcı bu ekranda neden duraksıyor?" sayısal değildir, kullanılabilirlik testi ve gözlem ister. Aynı çalışmadan iki cevabı birden beklemek ikisini de bulanıklaştırır.
A/B testinin çoğu listede atlanan bir ön koşulu var: trafik. Dönüşüm oranı %2 olan bir sayfaya haftada 200 ziyaret geliyorsa elinizde haftada dört dönüşüm vardır. Dört ile üç arasındaki farkı istatistik değil, tesadüf açıklar. Bu ölçekte A/B testi kurmak, sonucu okunamayacak bir deneye iki hafta harcamaktır. O iki haftayı beş kişiyle yapılacak bir kullanılabilirlik testine ayırın, en azından nedenine dair bir şey öğrenirsiniz.
Analitik ne söyler, ne söylemez
Analitik araçları nerede olunduğunu söyler: hangi sayfada durulmuş, nereden çıkılmış, hangi adım tamamlanmamış. Nedenini söylemez. Söylediğini iddia eden yorumlar genelde tahmindir ve tahmin olduğu unutulduğunda yol açtığı hasar, hiç veri toplamamış olmaktan büyüktür. Çıkış oranı yüksek bir sayfa kötü bir sayfa olabileceği gibi işini bitirmiş bir sayfa da olabilir; ikisini ayıran şey sayfanın kendisi değil, kullanıcının o adımda ne yapmaya çalıştığıdır.
Isı haritası eklentisi kurmadan önce sunucu loglarına bakın. En çok terk edilen adımı ve hata dönen istekleri birkaç satırlık bir sorguyla çıkarırsınız; üçüncü parti araca ve her sayfaya binen ek script yüküne gerek kalmaz. Araç, logun cevaplayamadığı bir soru ortaya çıktığında gelsin.
Arayüzde sıra, kullanıcının işine göre kurulur
Bir ekranın hiyerarşisi orada yapılan işin sıklığına göre belirlenir. Ayda bir açılan ayar, her gün kullanılan eylemle aynı görsel ağırlığı taşıyorsa ortada tasarım kararı değil, karar verilmemiş olması vardır.
Menüler tek yönlü büyür. Her kalem birinin talebiyle eklenir, hiçbiri kendiliğinden çıkmaz, hiyerarşi de zamanla düzleşir. Bunu geri almanın yolu yeni bir gruplama şeması icat etmek değil, kullanıcı yolculuğunu baştan sona çıkarıp adımları saymak ve iş akışına katkısı olmayanı silmektir. Silinen her adım, sonradan bakım da istemez.
Gerçek hayattan ilham, birebir kopya değil
Fiziksel dünyadan alınan metaforlar tanıdıklık sağlar ama bedava gelmez. Dijitalde klasörü klasör gibi çizerseniz kullanıcıya fiziksel klasörün kısıtlarını da miras bırakırsınız: nesne tek bir yere konur, aranırken açılması gerekir. Oysa dijital bir kaydın aynı anda beş etikete birden ait olmasının maliyeti sıfıra yakındır. Metaforu alın, kısıtını almayın.
Aynı ölçüt alışkanlıkları taklit etmek için de geçerli. İnsanların alışveriş sepetiyle kurduğu ilişki dijitalde işe yarar, çünkü sepet bir bekleme alanıdır ve bekleme alanına ihtiyaç gerçekten vardır. Fiziksel arşiv kutusunun sırt etiketi ise ekranda hiçbir işe yaramaz, çünkü ekranda arama kutusu var.
Kağıt, prototipten önce
Eskiz ucuz olduğu için değil, atılabilir olduğu için işe yarar. Bir ekrana iki gün emek verildiyse kimse onu gönül rahatlığıyla çöpe atmaz; tartışma da "bu doğru ekran mı" sorusundan çıkıp "bu ekranı nasıl kurtarırız" sorusuna kayar. Kaybedilen şey zaman değil, karardır.
Üç kaba eskizi masaya koyup ekibe gösterin, birinin neden elendiğini konuşun, kalanı ondan sonra dijitale taşıyın. Bu aşamada geri bildirim renk ve boşluk üzerine değil, akış üzerine gelir, çünkü kağıtta konuşulacak başka bir şey yoktur.
Kaynaklar