Yöneticiler İçin UX: Nerede Karar Verilir, Nerede Çekilinir
UX ekibiyle çalışan yöneticilerin çoğu tasarımın kendisine değil, kararın nerede verileceğine takılıyor. Araştırma ne zaman yapılır, test kime sorulur, bir arayüz değişikliği neye mal olur. Bunlar tasarım sorusu değil yönetim sorusudur, cevabı da tasarımcıdan değil işin sahibinden beklenir.
Araştırma her projede zorunlu değil, her projede ucuz da değil
Kullanıcı araştırmasını ilke haline getiren metinler genellikle bir cümle sonra "tek bir UX süreci yoktur, her proje farklıdır" der. İkisi bir arada durmaz. Süreç projeye göre değişiyorsa araştırma da bir bütçe kalemidir, dokunulmaz bir adım değil.
Pratikte ayrım şurada: yeni bir kitleye giriyorsanız, ya da ekip içinde "kullanıcı kim" sorusuna iki farklı cevap dolaşıyorsa görüşme yapın. Var olan bir akışta buton yerini değiştiriyorsanız görüşme yapmayın, ölçün. Birincisinde eksik olan bilgi, ikincisinde eksik olan veri.
Arayüz, deneyimin görünen yüzü
UX'i arayüz tasarımına indirgemek yöneticiler için cazip, çünkü arayüz gösterilebilir bir çıktı. Ekranın dışında kalanlar da deneyime dahil: teslimat süresi, destek talebine dönen cevap, faturanın anlaşılır olması.
Bu ayrımın bir de maliyet tarafı var. Ekranda üç tıka inen bir akış, arkada üç ayrı servise birden dokunuyorsa ucuz değildir. Tasarım kararını onaylamadan önce o kararın veritabanında ve entegrasyonlarda karşılığı olup olmadığını sorun; "bir haftalık iş" cevabı çoğu zaman arayüzü çizen kişiden değil, o veriyi taşıyacak kişiden gelmeli.
Küçük test, uzun toplantıyı bitirir
Kullanılabilirlik testinin asıl işlevi doğruyu bulmak değil, tartışmayı kapatmak. Beş kullanıcıyla yarım günde yapılan bir oturum, iki haftadır süren "bence kullanıcı burada takılır" tartışmasını bitirir. Kimin haklı olduğu belli olur ve ekip yoluna devam eder.
Bunun için laboratuvara, panele, düzeneğe gerek yok (çoğu şirkette bu ölçekte kurulum abartılı duruyor). Bir ekran kaydı, bir gözlemci ve konuşmayı bölmeyen bir moderatör yeterli. Testi büyüttükçe geciktirirsiniz, geciktirdikçe de karar zaten alınmış olur.
Süreci standartlaştırma isteğine direnin
Büyük kurumlarda UX'i şablona bağlama isteği yönetim ihtiyacından doğar: takvim, kilometre taşı, öngörülebilirlik. Ama aynı şablon hem üç ekranlık bir iç araca hem de altı ay sürecek bir yeniden tasarıma uygulandığında birincisi gereksiz belge üretir, ikincisi kritik adımları atlar. Standartlaştırılacaksa çıktı standartlaştırılsın: hangi kararın hangi kanıta dayandığı yazılı olsun. Yöntemin kendisi ekibe kalsın.
Tek kişilik UX ekibi diye bir şey yok
Araştırma, etkileşim tasarımı, içerik, arayüz kodu ve ölçümleme farklı işler. Bunları tek kişiye yıkmak mümkün, sonucu da tahmin edilebilir: o kişi en rahat ettiği işi yapar, geri kalanı yüzeysel kalır. Ekip küçükse rolleri değil, hangi işin bu çeyrekte yapılmayacağını netleştirin. Yapılmayacak işi yazmayan planlar, her şeyi yarım yapar.