UX Tasarım Pratiğini Geliştirmek: Rutini Nerede Kırmalı
UX pratiğini geliştirmek için verilen tavsiyeler çoğunlukla birbirinin tekrarı: daha çok oku, yeni araç dene, konfor alanından çık. Bir kısmı işe yarıyor, bir kısmı ise birbiriyle çelişiyor ve bu çelişki nadiren dile getiriliyor. Aşağıdakiler rutini gerçekten değiştiren birkaç alışkanlık, bir de aralarındaki gerilim.
Jargon uzmanlığın kanıtı değil
Alanına hakim olan herkes bir süre sonra kendi kısaltmalarıyla konuşmaya başlıyor. Sorun terimin kendisi değil, karşı tarafın kafasında o terime karşılık gelen bir şey olduğunu varsaymak. Bir projede geliştirici ekibe "kullanıcı akışında sürtünme var" dediğimde herkes başını salladı, iki hafta sonra dördümüzün dört ayrı şey anladığı ortaya çıktı.
Basit bir sağlama var: bulgunu jargon kullanmadan tek cümlede anlatamıyorsan, elinde henüz bulgu yok. "Sürtünme" değil, "kayıt formundaki telefon alanında kullanıcıların yarısı duraksadı". İkincisi tartışılabilir, birincisi sadece onaylanır.
Şablonla arşiv arasındaki gerilim
Aynı listede iki tavsiye yan yana durur: hazır araştırma şablonlarına bağlı kalma, esnek ol; ve eski projelerin bulgularını arşivle, tekrar kullan. Peki iyi tutulmuş bir arşiv nedir? Zamanla oluşmuş bir şablondur. Geçmiş projelerde çalışan soru setini yeni kullanıcıya taşıdığında esneklik iddiası orada biter.
Ayrım şurada: arşiv soru üretmek için değil, hipotez üretmek için iyi bir kaynak. Üç yıl önce yaptığın testte insanların filtre panelini görmediğini biliyorsun; bu, yeni görüşmede aynı soruyu sorma sebebi değil, o ekranda gözün açık olma sebebi. Eski soru listesini olduğu gibi açıp okumaya başlarsan görüşmeyi kendi geçmişine doğru yönlendirirsin.
Kendi sürecini denetlemek
Proje biter bitmez bir sonrakine geçmek en yaygın alışkanlık, ve gelişimi en çok yavaşlatan şey de bu. Ayda bir saatlik bir gözden geçirme yeter: hangi kararı hangi veriye dayandırdın, o veri gerçekten var mıydı, olmadığı yerde ne oldu.
Denetim yaparken sayıların nereden geldiğini de sorgulamakta fayda var. Nielsen Norman Group'un çok bilinen beş kullanıcı yeter önerisi bir formüle dayanır: n kullanıcıyla bulunan sorun oranı 1-(1-L)^n. Nielsen'in varsaydığı L değeri, yani tek kullanıcının bir sorunu yakalama olasılığı 0,31 alındığında beş kişi sorunların yaklaşık %85'ini buluyor. Ama L düşerse tablo değişir: nadir görülen, yalnızca belirli bir kullanıcı tipinde çıkan sorunlarda L 0,10 civarındaysa beş kişiyle bulacağın oran %41'e iner. Kural yanlış değil, koşullu. Homojen bir kullanıcı grubunda ve sık karşılaşılan sorunlarda geçerli; birden fazla kullanıcı tipi varsa her tip için ayrı beş kişi demek.
Yeni araç mı, aynı işi farklı yerde yapmak mı
Yeni prototipleme yazılımı denemek öğrenme gibi hissettirir, çoğu zaman erteleme olur. Aracı değiştirmek pratiği değiştirmez; değiştiren şey, o araçla daha önce yapmadığın bir şeyi yapmaktır. Kendi tasarımını koda dökmek, bir sprintte ürün yönetimi tarafında oturmak ya da destek taleplerini bir hafta okumak, üç yeni Figma eklentisinden fazlasını verir. Tasarladığın bileşeni bir kez kendin uyguladığında, o bileşenin durum sayısının sandığından fazla olduğunu görürsün: yükleniyor, boş, hata, kısmi veri. Bunlar tasarım dosyasında yoktur, kodda vardır.
Okuma zamanını takvime yaz
"Boş vakit bulunca okurum" diyen kimsenin boş vakti olmuyor. Haftada bir saatlik bir blok, kitap ya da uzun bir vaka çalışması için yeterli; kısa blog yazılarını takip etmek bilgi toplama hissi verir ama derinlik bırakmaz. Okuduğunu bir yere not etmek de gerekiyor, çünkü altı ay sonra hatırlayacağın tek şey not aldığın kısım olacak.