Tasarım Eleştirisi Toplantısı Neden Dağılır
Tasarım eleştirisi toplantılarının dağılmasını genelde katılımcıların disiplinsizliğine bağlarız. Sebep çoğu zaman daha basit: toplantıya net bir soru sorulmadan giriliyor. Ekrana tasarımı yansıtıp "ne düşünüyorsunuz" dediğinizde gelen cevap dağınıksa, dağınıklık soruda başlıyor.
Toplantının sorusunu yaz, sözle geçiştirme
Geri bildirim kurallarını toplantı başında söylemek yetmiyor; ilk beş dakikadan sonra kimse hatırlamıyor. Soruyu ekranın bir köşesinde yazılı tut: bugün akışı mı tartışıyoruz, metni mi, yoksa görsel dili mi? Yazılı soru, konu dışına çıkan bir yorumu kesmek için tartışmaya gerek bırakmıyor, yorumu yapan kişi kendi kendini durduruyor.
Bu, teknik olmayan katılımcıların susması anlamına gelmiyor. Tersine, neyin sorulduğunu bilen biri konuşmaya daha rahat giriyor. Toplantıyı dağıtan şey fazla cesaret değil, hedefin belirsizliği.
"Ya şöyle olursa?" trafiğini kesmek
Hipotetik senaryolar çoğaldığında bilinen tavsiye şu: tartışmayı durdur, senaryoları beyaz tahtaya topla, sonra gerçekleşme olasılığına göre oyla. İlk yarısı işliyor. İkinci yarısı kendini yiyor, çünkü odaya "bu ne kadar olası" diye sormak, az önce kesmeye çalıştığınız spekülasyonu oylama kılığında geri getiriyor. Elinde veri olmayan on kişinin ortalaması da veri değil.
Oylama yerine her senaryoya tek bir soru sorun: bunu nereden biliyoruz? Cevabı bir destek kaydı, analitik ekranı ya da kullanıcı görüşmesi olan senaryo tartışmaya girer. Cevabı "bana öyle geliyor" olan senaryo silinmez, araştırma listesine yazılır ve o toplantıda kapanır. O liste bir sonraki araştırma turunun gündemi olur; tasarım kararının gerekçesi olmaz.
Subjektif yorumu aksiyona çevirmek
"Sanki bir şey eksik" türü yorumlar toplantının kaçınılmaz parçası. Gelen her geri bildirimi üç kutudan birine koyarak ilerleyin:
- Yapılacak: ikna olduğunuz, doğrudan uygulanacak öneri.
- Tartışılacak: ürünün hedefiyle çelişen, karar gerektiren öneri.
- Netleşecek: ne istendiği anlaşılmayan, sahibine geri sorulacak yorum.
Kutulardan ikincisi kontrolden çıkmaya en yatkın olanı. Bir yoruma "tartışılacak" demek, onu nazikçe ertelemenin yolu haline gelebiliyor. Bu yüzden her satırın yanına kimin karar vereceğini ve ne zaman kapanacağını yazın. Sahibi yazılmayan madde kapanmıyor, sadece bir sonraki toplantıya taşınıyor.
Eleştiri toplantısına geliştirme tarafından birinin katılmasını genelde şart koşarım. "Şu alanı da kullanıcı seçsin" önerisinin iki saatlik mi iki haftalık mı olduğunu orada söyleyecek biri yoksa birinci kutu gerçekçiliğini kaybediyor, haftaya maddelerin yarısı geri dönüyor.
Bekleme alanı ancak işletilirse işe yarar
Gündem dışına çıkan ama değerini kaybetmeyen konular için bir "bekleme alanı" tutmak yaygın pratik. Pratikte çoğu bekleme alanı, konuyu kibarca kapatmanın adı oluyor: kimse o listeyi bir daha açmıyor. Listenin gerçekten çalışması için iki sıkıcı şey gerekiyor, listenin bir sahibi olması ve bir sonraki toplantının ilk maddesi olarak açılması.
Aynı şey bilgi panosu için de geçerli. Trello ya da Notion'da açtığınız pano, tartışma sırasında uçup gidecek varsayımları tuttuğu için değerli; iki hafta sonra kimse girmiyorsa pano değil mezarlık. Panoyu projenin mevcut ritmine bağlayın, ayrı bir alışkanlık olarak kurmaya çalışmayın.
Bu kuralların hiçbiri eleştiriyi yumuşatmıyor, sert geri bildirim gelmeye devam edecek. Değişen şey toplantıdan çıkarken elinizde ne olduğu: bir izlenim bulutu değil, satır satır sahibi belli bir liste.