UX Teslimatını Bozan Dört Sorun ve Aralarındaki Çelişki
UX projeleri nadiren teknik bir sebeple raydan çıkar. Teslimatı bozan şey genelde en başta sorulmamış bir soru, ikinci projeye olduğu gibi taşınmış bir süreç ya da kimsenin itiraz etmediği bir karar oluyor. Dördü klasikleşmiş durumda. İlginç olan, bu dördün ikisinin birbiriyle çelişen tavsiyeler üretmesi.
Araştırma neden ilk kesilen kalem
Deneyim arttıkça araştırma kısalıyor, bir yerden sonra tamamen düşüyor. Refleks anlaşılır: onuncu ödeme akışını tasarlayan biri sepette ne olup bittiğini gerçekten biliyordur. Bildiği şey bu projenin kullanıcısı değil, önceki dokuz projenin kullanıcısı. Fark da tam orada duruyor.
Bütçe gerçekten yoksa soruyu değiştir. “Kullanıcıyı nasıl tanırım” yerine “bu projede yanılırsam en pahalıya patlayacak varsayım hangisi” diye sor. Cevap çoğunlukla tek bir maddedir ve yarım günlük beş görüşme onu ya doğrular ya yıkar (beş sayısının biraz fetişleştirildiğini düşünüyorum, ama fikir yerinde). Araştırmanın tamamını değil, en riskli parçasını satın almış olursun.
Bir de bedavası var: destek kayıtları, site içi arama sorguları, formun terk edildiği adım. Bunlar araştırmanın yerine geçmez, neyin sorulmaya değer olduğunu söyler.
Aynı süreci her projeye giydirmek
Bir kez işe yarayan atölye formatı, ikinci projede kendiliğinden “bizim yöntemimiz” oluyor. Sorun formatta değil, formatın neden işe yaradığının unutulmasında. O atölye belki de karar veren üç kişi aynı odada olduğu için yürümüştü. Karar beş departmana dağıldığında aynı atölye üç saatlik bir fikir turnuvasına dönüşür ve kimse çıkışta ne karar verildiğini söyleyemez.
Peki tersini denesek? Süreci hiç sabitlememek de çalışmıyor; ekip neyi ne zaman yapacağını kestiremeyince her proje yeniden müzakere edilen bir takvime dönüşüyor. Denge şurada duruyor: aşamalar sabit kalsın, aşamaların içi projeye göre değişsin. Kullanıcıyı anlama aşaması her projede var, onu anketle mi, saha ziyaretiyle mi, destek kayıtlarıyla mı dolduracağın projeye bağlı.
“Ders çıkar” ile “şablonu taşıma” çelişkisi
Bu iki tavsiye aynı listede yan yana duruyor ve birbirini yiyor. Geçmiş projelerden öğren deniyor, hemen ardından geçmişte işe yarayanı yeni projeye taşıma deniyor. İkisi aynı anda nasıl olacak?
Ayrım basit: taşınabilir olan çözüm değil, hata biçimi. “Onay ekranını en sona koyduk, kullanıcılar geri dönemedi” bir çözüm değil, bir başarısızlık kaydıdır ve bir sonraki projede nereye bakacağını söyler. Çözümün kendisi, yani o projede onay ekranını nereye taşıdığın, bağlama ait bilgidir; başka projeye kopyalandığında yanlış problemi çözer.
Pratikte bu, ekipte tutulması gereken iki ayrı listeye karşılık geliyor. Yaptığımız işler listesi her yerde var. Yanıldığımız yerler listesi neredeyse hiçbir yerde yok.
Odadaki en deneyimli kişi olmak
Uzmanlık arttıkça itiraz azalıyor, çünkü itiraz etmenin bedeli yükseliyor. Junior tasarımcı yanlış bulduğu akışı üç kere söylüyor, dördüncüde susuyor. Ekipte fikir birliği varmış gibi görünen anların önemli bir kısmı budur.
Kararı yazılı savunmayı zorunlu kılmak işe yarıyor. Bir akışı neden böyle kurduğunu tek cümleyle yazamıyorsan o karar büyük ihtimalle alışkanlıktır. Yazıldığı anda tartışılabilir hale gelir; sözlü kararlar tartışılmaz, sadece onaylanır.
Müşterinin itirazı da veri. “Bu buton burada olmasın” cümlesi çoğu zaman bir tasarım eleştirisi değil, dile getirilmemiş bir kısıtın habercisidir: satış ekibi o adımda telefon açıyordur, ya da sayfayı hukuk onaylıyordur. Butonu tartışmaya başlamadan önce kısıtı sormak gerekiyor, yoksa üç tur döner ve aynı yere gelinir.
Kaynaklar