Şirket İçi UX Evangelizmi Nerede Tıkanır
UX evangelizmi denince akla toplantıdan toplantıya koşan, herkesi kullanıcı odaklılığa ikna etmeye çalışan biri geliyor. Kelimenin kendisi bir şeyi ele veriyor: misyonerlik, karar masasında yeri olmayanın başvurduğu yöntemdir. Konuyla ilgili yazıların çoğu bu tıkanmayı çözmek yerine daha iyi sunum yapmayı öneriyor.
İkna gerekiyorsa yetki eksiktir
Bir organizasyonda hiç kimse muhasebeye borç kaydının niye tutulması gerektiğini anlatmıyor. Çünkü o karar bir bütçe kaleminde, bir sorumluda ve bir sistemde yerleşik. UX'in sunumla anlatılıyor olması, aynı yerleşikliğin kurulmadığının işareti.
Bu yüzden "liderlik desteği alın" tavsiyesi tek başına havada kalıyor. Yönetimin toplantıda kullanıcı odaklılıktan söz etmesi ucuz; asıl soru şu: kullanıcı araştırması bir özelliğin çıkışını geciktirdiğinde kim hayır diyebiliyor? O yetki kimsede yoksa, destek beyanının pratikte karşılığı yok.
Somut hali çoğu zaman şuna iner: tanım-of-done'a kullanılabilirlik maddesi eklemek, sprint kapanışını buna bağlamak, bir kişiye reddetme yetkisi vermek. Bunlar sunum değil, süreç değişikliği. Zor olan da bu, çünkü kimsenin takvimine dokunmadan yapılamıyor.
"Herkesin sorumluluğu" ile "doğru kişiler" aynı anda olmaz
UX yazınında iki tavsiye yan yana durur ve birbirini keser. Bir yandan kullanıcı deneyimi tek bir departmanın işi değil, tüm şirketin ortak sorumluluğudur denir. Öte yandan herkesi sürece dahil etmeyin, bilgi kirliliği yaratır, odaklanın denir. İkisi birden geçerli olamaz.
Çelişki, iki farklı şeyin aynı kelimeyle anılmasından çıkıyor. Kullanıcının yaşadığı sonuçtan gerçekten herkes sorumlu: destek yazışmasının tonu da, hata mesajının metni de deneyimin parçası. Ama araştırma yapmak, bulguyu yorumlamak ve önceliklendirmek belirli birkaç kişinin işi. Sorumluluğu yaymak ile karar hakkını yaymak karıştırılınca, ortaya kimsenin sahiplenmediği bir alan çıkıyor.
Pratik ayrım basit: bulguyu kim üretiyor, kim önceliklendiriyor, kim uyguluyor. Üçünü tek listeye koymak yerine ayırın; katılımcı sayısı kendiliğinden makul yere iner.
Memnuniyet metrikleri UX'in etkisini izole etmiyor
Programın başarısını NPS ve CSAT ile ölçme tavsiyesi çok tekrarlanıyor, ama bu metrikler tam olarak sorulan soruya cevap vermiyor. NPS tek bir tavsiye sorusundan gelir ve fiyattan, kampanyadan, teslimat süresinden, sektörün genel havasından etkilenir. Aynı çeyrekte hem arayüzü sadeleştirip hem indirim yaptıysanız, puandaki artışın hangi kısmının tasarımdan geldiğini söyleyemezsiniz.
Daha dar ve daha dürüst ölçüler var: belirli bir akışta görev tamamlama oranı, ilk denemede tamamlama, aynı ekrandan gelen destek kaydı sayısı, formda terk edilen adım. Bunlar tek bir değişikliğe bağlanabildiği için bir sonraki kararı da besliyor. Şirket geneli bir memnuniyet skoru ise ancak yıllık sunumda işe yarıyor.
Ölçümü değişikliğin öncesi ve sonrasıyla eşleştirin, tek noktadan bakmayın. Rakamın yönü, mutlak değerinden daha çok şey anlatır.
İkna yerine işe yarayan şey
Kullanıcı araştırması raporları okunmadığı için değil, kimsenin iş listesine girmediği için ölü kalıyor. Bir kurumsal projede kullanılabilirlik testi raporunu üç ay kimse açmadı; testi tekrarlamak yerine bulguları tek tek backlog maddesi olarak yazdığımızda ilk hafta ikisi kapandı. Rapor bir belge, madde ise birinin üzerine atanabilen bir iş.
Bunun dışında işe yaradığını gördüğüm birkaç şey var. Geliştiricileri test seansına izleyici olarak sokmak, otuz slaytlık sunumdan daha hızlı ikna ediyor; kendi yazdığı ekranda birinin tıkandığını izleyen kişiye ayrıca anlatmak gerekmiyor. Bulguyu ürün diline çevirmek de öyle: "kullanıcılar zorlanıyor" cümlesi hiçbir toplantıda karar üretmez, "kayıt akışının üçüncü adımında her on kişiden dördü düşüyor" cümlesi üretir.
Eğitim ve farkındalık çalışmaları listenin en altında duruyor. Kötü değiller, ama bir sonraki sürümde ne değişeceğini belirleyen şey nadiren eğitim oluyor.
Kaynaklar