UX Tasarımının Şirket İçinde Karşılık Bulması
Bir tasarım önerisinin reddedilmesinin en yaygın nedeni kötü olması değil, kimsenin onu kendi işine bağlayamamasıdır. UX ekipleri kullanıcıyı anlamak için haftalar harcar, sonra aynı titizliği yan masadaki geliştiriciye ya da ürün yöneticisine göstermez. Şirket içindeki karşılık, araştırmanın kalitesinden çok önerinin kimin takvimine ne kadar yük bindirdiğiyle belirlenir.
Öneri neden takılır
Yöneticinin UX'i anlamadığı iddiası çoğu vakada yanlıştır. Anlamadığı şey UX değil, o önerinin çeyreklik hedefine ne yaptığıdır. Geliştirici tarafında da durum benzer: itiraz tasarımın kendisine değil, tasarımın dokunduğu yere gelir.
Persona, yolculuk haritası, kullanılabilirlik testi. Bunlar bir kanıt paketi üretir. Kanıt tek başına karar değiştirmez; karar, o kanıt birinin bütçesine veya takvimine bağlandığı anda değişir. Sunum biter, herkes başını sallar, hiçbir şey olmaz. Bu tabloda bulgular genelde doğrudur, eksik olan muhataptır.
Empati haritasını dışarıya değil içeriye çevir
Empati haritası kullanıcı araştırmasının aracı sayılır, oysa asıl işi ikna edilecek tarafı anlamaktır. Yöneticiye, geliştiriciye, satışçıya ayrı ayrı çıkarıldığında önerinin hangi cümleyle sunulacağı kendiliğinden ortaya çıkar.
Her paydaşta cevabını aradığın üç şey var:
- Bu çeyrek neye göre değerlendiriliyor. Dönüşüm oranı mı, hata sayısı mı, teslim tarihi mi.
- Geçen sefer benzer bir değişiklik önerildiğinde ne oldu. Kırılan bir şey varsa direncin kaynağı tasarım değil, o hatıradır.
- Öneriyi uygularsa kimin işi artar. Cevap kendisiyse ikna metni tamamen değişir.
Bu üç sorunun cevabı toplantıda değil, koridorda ve birebir görüşmede çıkar. Grup toplantısında herkes kurumsal cevabı verir.
Atölyenin faturası
Ortak tasarım tavsiyesi genelde koşulsuz verilir: herkesi erken dahil et, birlikte üret. Aritmetiği kimse yazmaz. Sekiz kişilik iki saatlik bir atölye on altı kişi-saat eder. Ayda dört kez tekrarlarsan altmış dört saat, yani tam zamanlı bir kişinin aylık mesaisinin yaklaşık yüzde kırkı sadece bu toplantılara gider. Karşılığında ne aldığın belliyse sorun yok. Belli değilse, ekip "UX süreci yavaşlatıyor" kanaatine bu hesabın içinden varır.
Atölye, geri dönüşü pahalı kararlar için doğru araçtır: bilgi mimarisi, ana akışın kurgusu, veri modelini etkileyen her şey. Buton yerleşimi ve metin değişikliği için iki kişiye ayrı ayrı sorulan yirmi dakika, sekiz kişilik oturumdan hem hızlı hem dürüst sonuç verir, çünkü kalabalıkta itiraz yumuşar.
Maliyeti bilinen öneri kabul görür
Bir öneriyi götürmeden önce o ekranın hangi katmana dokunduğunu sor. Cevap yalnızca görünümse toplantı kurmana gerek yok, iş bir öğleden sonrada biter ve onay almanın en hızlı yolu doğrudan geliştiriciyle konuşmaktır. Cevap veri modeliyse toplantıyı zaten kurman gerekir, çünkü orada tartışılan şey tasarım değil göç planıdır. Bu ayrımı yapmadan gidilen her öneri, geliştiricinin zihninde en pahalı ihtimalle fiyatlanır.
Tahmini rakamla sunulan öneri de aynı işi görür. "Bu akışı iki adıma indirelim" cümlesi ile "bu akış üç ekranda yaşıyor, ikisinin şablonu ortak, tahmini iki gün" cümlesi aynı odada farklı karşılanır. Rakam yanlış çıkabilir; yine de öneriyi soyut bir istek olmaktan çıkarır.
Şeffaflık aracı, süreci değil
Slack, Teams, proje panosu. Bunlar iletişimi hızlandırır, kurmaz. Kararın nerede alındığı belli değilse araç sayısını artırmak yalnızca aynı tartışmanın üç kanala dağılmasına yarar. Tasarım kararlarının tek bir yerde, gerekçesiyle yazılı durması, hangi araçta durduğundan daha belirleyicidir. Altı ay sonra "bu neden böyle" sorusuna cevap veren şey o kayıttır.
Kurum içi kabul, tasarımın kalitesinin doğal sonucu değildir. Araştırmayı paydaşın diline çeviren, maliyeti önceden söyleyen ve kararı yazılı bırakan ekip kabul görür. Bunları yapmayan ekip, doğru bulgularla yıllarca reddedilmeye devam eder.
Kaynaklar