Kurum İçi UX Rolünde Etkiyi Anlatmak Değil Ölçmek
Kurum içi UX tasarımcısının en sık duyduğu tavsiye, işinin değerini yöneticilere iyi anlatması gerektiğidir. Anlatımın gayet yerinde olduğu halde bütçenin yine de kesildiği durumlar var, çünkü sunumun ikna etmeye çalıştığı şey başka şirketlerin verisi. Peki bu rolde kendi kurumunda neyi kaydetmek gerçekten işe yarıyor?
Başka şirketin verisi seni kurtarmıyor
"Kullanıcı deneyimine yatırım yapan şirketlerde memnuniyet artıyor" cümlesi doğru olabilir, ama toplantıda karşı tarafın aklına gelen ilk soru şu oluyor: bizde de arttı mı? Sunumda gösterdiğin vaka bir e-ticaret devine aitse, senin kurumunun bayi paneline dair hiçbir şey söylemiyor. Genel araştırmalar UX'in ne olduğunu tartışmayı bitirmek için işe yarar, bütçe konuşmasını kazanmak için değil.
Kendi rakamını üretmenin maliyeti çoğu insanın sandığından düşük. Bir formun hangi adımında terk edildiğini öğrenmek için pahalı bir analitik paketini beklemene gerek yok; alan bazında odak ve gönderim olaylarını kendi tablona yazarsan, bir hafta sonra elinde tartışılmayacak bir dağılım olur. Aynı şey destek tarafında da geçerli: gelen talepleri konu başlığına göre etiketlemek bir günlük iş, ama üç ay sonra "şu ekran yüzünden ayda kaç kişi bize yazıyor" sorusuna cevap verir.
Neyi kaydetmeli
- Tekrar eden destek talepleri, ekran bazında gruplanmış halde
- Akış içinde terk noktaları, adım adım
- Bir işi tamamlamak için gereken tıklama ya da ekran sayısı, değişiklikten önce ve sonra
Bunların hiçbiri kullanıcı memnuniyeti ölçmez. Ölçmesi de gerekmiyor. Bütçeyi konuşan kişinin duymak istediği şey memnuniyet değil, azalan yük.
Gerçek müttefik pazarlama değil, destek ekibi
Kurum içi UX yazılarının çoğu "tüm paydaşlarla düzenli iletişim kurun" diyerek geçiyor. Herkesle eşit yakınlıkta olmak pratikte kimseyle yakın olmamak demek. Sınırlı zamanını nereye koyacaksan, müşteri destek ekibine koy.
Nedeni basit: kurumdaki tek doğal kullanıcı araştırması verisi zaten onların kayıtlarında duruyor, üstelik ücretsiz ve geçmişe dönük. Bir tasarım değişikliğinin işe yarayıp yaramadığını en erken onlar fark eder, çünkü şikayet akışı seninkinden önce değişir. Buna karşılık pazarlama ekibiyle kurulan ilişki genelde tek yönlü çalışır, senden görsel ister, sana veri vermez.
Ürün yöneticisiyle ilişki ise ayrı bir mesele. Orada kurulacak şey iyi niyet değil, ortak bir tanım: hangi işin "bitti" sayıldığı. Kullanılabilirlik testinin geliştirme bittikten sonra yapıldığı bir takımda, bulguların hiçbiri o sürüme giremez.
Kaynak yokken genişlemenin gizli faturası
Tek kişilik UX ekiplerine verilen standart tavsiye, başka bölümlerden insanları küçük araştırmalara dahil etmek. Fikir sağlam, ama tavsiyenin genelde söylenmeyen bir yanı var: ilk turda bu seni yavaşlatır.
Üç seanslık bir kullanılabilirlik testini kendin yaparsan üç saatlik iş. Pazarlamadan birine öğreterek yaptırırsan, hazırlık, gözlem ve sonrasında notların düzeltilmesiyle birlikte bunun en az iki katı. Yani ilk proje zarar yazar. İkinci projeden itibaren kâra geçersin, üçüncüde artık iki kişi oluyorsunuzdur. Bunu bilerek yapmakla, "işbirliği verimlilik getirir" diye yapıp ilk turda hayal kırıklığına uğramak arasında ciddi fark var.
Aynı hesap, sabır tavsiyesiyle de çelişiyor. Kurum içi UX yazıları hem "sabırlı ol, kültür değişimi yıllar alır" der, hem "kaynak yoksa başkalarını dahil et". İkincisi tam olarak sabrın bittiği yerde başvurulan yöntem. Kimi dahil edeceğine karar verirken kriter hevesli olması değil, o kişinin ekibinin senin ölçtüğün sayıdan etkileniyor olması.
Şablon kütüphanesi ölür, karar kaydı yaşar
Merkezi bir doküman kütüphanesi kurma önerisi her listede var. Kurulanların çoğu altı ay içinde terk ediliyor, çünkü şablon güncellenmediği anda aktif olarak yanlış yönlendirmeye başlıyor; eski bileşen adları, kaldırılmış ekranlar, artık geçerli olmayan renk kararları.
Zamana dayanan tek şey karar kaydı oluyor: hangi tasarım tercihinin ne zaman, hangi gerekçeyle yapıldığı ve neyin denenip bırakıldığı. Üç satırlık bir kayıt yeter. Bunun değeri altı ay sonra biri "neden burada modal kullanmışız" diye sorduğunda ortaya çıkar, ve bu soru mutlaka sorulur. Karar kaydını tasarım dosyasının içine değil, geliştiricinin zaten baktığı yere koy; ayrı bir araca taşıdığın anda kimse açmaz.
Kaynaklar