UX Projelerinde Paydaş Katılımı: Kararı Kim Veriyor?

UX projelerinde işi tıkayan şey çoğu zaman tasarımın kendisi değil, kararın kimde olduğunun belirsiz kalması. Paydaş katılımı bu yüzden bir iletişim nezaketi değil, planın parçası. Aşağıdakiler toplantı sayısını artırmadan işleyen pratikler.

Önce onay ile bilgiyi ayırın

Paydaş listesi çıkarmak kolay, işe yaramaz halini üretmek daha da kolay. Listeyi unvanlara göre değil, iki soruya göre kurun: bu kişi olmadan hangi karar alınamaz, bu kişi bilgilendirilmezse hangi iş iki kere yapılır. Birinci gruptakiler onay verir, ikinci gruptakiler haberdar edilir. Karışırsa şu olur: onay verecek kişi haftalık raporda kaybolur, sadece bilgilendirilmesi gereken kişi tasarım toplantısında fikir yürütmeye başlar.

Katılım seviyesini baştan yazın

Her paydaşın projeye dahil olma derecesi farklı, ve bunu ilk haftada yazmak sonradan çıkacak tartışmayı bitiriyor:

• Bilgilendirilen: Süreci takip eder, geri bildirimi bağlayıcı değildir.
• Danışılan: Belirli dönemeçlerde fikri sorulur.
• Katkı veren: Düzenli geri bildirim verir, çıktının şeklini etkiler.
• Ortak çalışan: Ekibin parçası gibi çalışır, kararlara katılır.
• Karar veren: Onay ve sorumluluk kendisinde.

Bu satırları projeye başlarken paydaşın kendisiyle teyit edin. Kimse “sen sadece bilgilendirilensin” cümlesini altı ay sonra, tasarım kilitlendikten sonra duymak istemiyor.

Teknik ekibi onay aşamasında değil, eskiz aşamasında çağırın

Yaygın hata, yazılım ekibini tasarım imzalandıktan sonra sürece almak. O noktada gelen tek şey maliyet haberi oluyor, üstelik geri dönüşü pahalı bir anda. Oysa ekranın kabataslak halinde “bunu iki haftada çıkarabilir miyiz” sorusunu sormak bedava. Filtrelemeyi istemci tarafında mı yoksa sunucuda mı yapacağınız gibi bir ayrıntı, arayüzde anlık sonuç gösterip gösteremeyeceğinizi belirliyor; bunu prototip aşamasında öğrenirseniz tasarım ona göre şekilleniyor, sonra öğrenirseniz tasarım kırpılıyor.

Aynı şey ölçüm için de geçerli. “Kullanıcıların bu adımda ne yaptığını izleyeceğiz” cümlesi, o olayların kod tarafında gerçekten üretiliyor olmasına bağlı. Araştırma planını yazarken hangi olayın hâlihazırda kayıtlı olduğunu sormak, üç ay sonra veri olmadığını fark etmekten iyi.

Toplantının maliyetini hesaplayın

Sekiz paydaşla haftada yarım saatlik birebir görüşme, ekip tarafında dört saat demek. Karşı tarafta da aynı dört saat. Aylık toplamı otuz saatin üzerine çıkıyor, yani bir kişinin haftasının neredeyse tamamı. Bu bütçeyi kabul ediyorsanız sorun yok; kabul etmiyorsanız görüşme sıklığını katılım seviyesine göre ayırın. Karar verenle iki haftada bir, bilgilendirilenle ayda bir yazılı özet çoğu projede yetiyor.

Katılım planı tek sayfa olsun

Paydaş başına doküman üretmek kulağa düzenli geliyor ama bu dokümanlar projeden hızlı eskiyor. Tek bir tabloda tutun: kişi, ekipten muhatabı, katılım seviyesi, başarı ölçütü, bilinen endişesi. Beş sütun. Yeni katılan ekip üyesi bunu on dakikada okuyabiliyorsa iş görüyor, okuyamıyorsa zaten kimse güncellemeyecek.

Paydaş	Muhatap	Seviye	Başarı ölçütü	Endişesi
Satış müdürü	Ürün sahibi	Danışılan	Demo süresinin kısalması	Yeni akışın eğitimi

Direnç nereden geliyor

Paydaş direncini kurumun UX olgunluk seviyesine bağlamam. Olgunluk modelleri kurumu tarif etmekte işe yarıyor, ama masadaki itirazı açıklamıyor. İtirazların çoğu kimsenin sormadığı bir maliyet kaleminden çıkıyor: destek ekibinin yeni akışı öğrenmesi gereken iki hafta, satışın demo senaryosunu baştan çekmesi, ya da eski ekranla entegre çalışan bir raporun bozulacak olması. Bunlar sorulduğunda dile geliyor, sorulmadığında son onay toplantısında “bence buna hazır değiliz” şeklinde geri geliyor.

Pratik karşılığı şu: paydaş görüşmesinde “bu tasarım hakkında ne düşünüyorsunuz” yerine “bu değişiklik sizin tarafınızda neyi bozar” diye sorun. İkinci soru somut cevap üretiyor, birincisi görgü kuralı.