Konu Başlıkları
Yükleniyor...

UX Ekiplerinin Sorunu Bütçe mi, Karar Sırası mı?

UX Yönetimi: Destek Söylemi ve Ekip Büyüklüğü

Kurumsal UX yazılarının vardığı yer genelde aynı: yönetim desteklesin, bütçe artsın, masada bir UX temsilcisi bulunsun. Liste yanlış değil ama nedenle sonucu karıştırıyor. Desteklenen ekiplerden iyi tasarım çıkması, desteğin o tasarımı ürettiği anlamına gelmez; çoğu kurumda darboğaz kaynağın miktarı değil, kararın hangi aşamada alındığıdır.

Destek eksikliği mi, geç çağrılmak mı?

"Yönetim UX'i desteklemiyor" cümlesi çoğu zaman başka bir şeyi anlatır: ekip, çözüm zaten seçildikten sonra çağrılmıştır. Kapsam belli, veri modeli çizilmiş, sprint planlanmış; UX'ten beklenen, kararın üzerine düzgün bir ekran geçirmektir. Böyle bir kurulumda bütçeyi ikiye katlasanız da çıktı değişmez, sadece daha pahalı ekranlar elde edersiniz.

Farkı görmenin pratik yolu, bulgunun geldiği anın maliyetine bakmak. Bir butonun yerini ya da metnini değiştirmek arayüz katmanında kalır, yarım günlük iştir. Kayıt akışını ikiye bölmek ya da bir alanı zorunluluktan çıkarmak veri modeline dokunur: şema değişikliği, geçiş betiği, eski kayıtların ne olacağı sorusu. Aynı araştırma bulgusu, iki hafta erken geldiğinde ucuz, iki hafta geç geldiğinde pazarlık konusu olur. Ekiplerin "bize kulak verilmiyor" dediği durumların önemli bir kısmı aslında bu takvim farkıdır.

Masaya bir sandalye eklemek neyi çözer?

Yaygın öneri, üst yönetimde UX unvanı açmak. Bunun bir faydası var: bütçe tartışmasında konuyu savunacak biri bulunur. Ama tek başına unvan, kararın nerede alındığını değiştirmiyor (bu unvan enflasyonunu biraz şüpheyle karşılıyorum). Direktör atanmış ama araştırma bulgusu hâlâ tasarım bittikten sonra masaya geliyorsa, değişen şey toplantı katılımcı listesidir.

Burada aynı metinlerin sık düştüğü bir çelişki de var. Bir yanda "hiyerarşide UX'e yeni kademeler açın", diğer yanda "küçük ve çevik ekipler daha etkin" deniyor. İkisi aynı anda savunulamaz. Katman eklemek, bir kararın geçtiği onay sayısını artırır; küçük ekibin avantajı ise tam olarak o onayların yokluğundan gelir.

Küçük ekibin avantajı sihir değil, aritmetik

Küçük ekiplerin hızı çoğu yazıda kültürel bir meziyet gibi anlatılır. Oysa hesabı basit: n kişilik bir ekipte kurulması gereken ikili iletişim kanalı sayısı n(n-1)/2 kadardır. Beş kişide 10 kanal, on iki kişide 66. Ekip iki katına çıkarken koordinasyon yükü dört katına yaklaşır ve bu yük kimsenin takviminde görünmez, sadece kararların yavaşlaması olarak hissedilir.

Ama küçüklük tek başına yetmiyor. Karar yetkisi başka yerde duran beş kişilik bir ekip, sadece daha hızlı hayal kırıklığına uğrar. Ekibin küçük olmasının işe yaradığı yer, o ekibin kendi kapsamı içinde onay almadan karar verebildiği durumdur.

Pratikte karşılığı olan üç değişiklik

Yönetim tarafında gerçekten fark yaratanlar, kültür söyleminden çok takvim ve yetki düzenlemeleri:

  • Araştırmayı takvimde sabitlemek. "Zaman bulursak kullanıcıyla konuşuruz" pratikte hiç konuşmamak demek. Her sürüm döngüsünde beş kullanıcı ve iki saatlik bir slot, esnek bırakılan büyük bir araştırma bütçesinden daha çok iş görür.
  • Kararın gerekçesini yazmak. Hangi tasarım kararının hangi gözleme dayandığı tek paragrafla kayıt altına alındığında, altı ay sonra "bunu neden böyle yapmıştık" tartışması bitiyor ve karar kişiye bağlı olmaktan çıkıyor.
  • Yanlışlama ölçütünü baştan belirlemek. Bir akış değişikliğini hangi metriğin yanlışlayacağını önceden yazmayan ekip, sonucu ne çıkarsa çıksın onu başarı olarak yorumlar.

Bunların hiçbiri yeni unvan ya da yeni araç gerektirmiyor. Üçü de kararın sırasını değiştirdiği için işe yarıyor; yönetim desteği dediğimiz şeyin ölçülebilir kısmı da zaten bu.