İnsan Odaklı Tasarım: Semptomu Değil Kök Nedeni Görmek

İnsan odaklı tasarım denince akla önce kullanıcı görüşmeleri ve empati haritaları gelir, oysa yaklaşımın ayırt edici tarafı problemi nerede kestiğidir. Kullanıcının şikâyet ettiği şey çoğu zaman problemin kendisi değil, görünen ucudur. O ucu düzeltmek hızlı sonuç verir; sorun birkaç ay sonra başka bir yerden geri gelir.

Dört ilke, tek tek

Yaklaşımı dört maddeye indirgemek mümkün, ama maddeler ancak ne işe yaradıklarını bilince anlam kazanıyor.

• İnsanlara odaklanmak: Kullanıcının ne istediğini değil, ne yapmaya çalıştığını anlamak. Bu ikisi çoğu zaman aynı cümleyle ifade edilmez.
• Kök problemi hedeflemek: Görünen belirtiyi değil, onu üreten mekanizmayı ele almak.
• Sistem düzeyinde düşünmek: Parçaların birbirini nasıl beslediğini görmek, tek bir parçayı izole edip iyileştirmemek.
• Küçük adımlarla ilerlemek: Her adımı denenebilir tutmak, böylece yanlış varsayım ucuza ortaya çıkar.

Klasik örnek sağlıktan geliyor. Çocuklar MR cihazına girmeye korktuğu için çekimlerin önemli bir kısmı sedasyon gerektiriyordu. Doug Dietz'in GE için geliştirdiği çözüm cihazı değiştirmedi; odayı korsan gemisine, çekimi de çocuğun içinde rol aldığı bir maceraya çevirdi. Teknik problem sanıldığı gibi görüntüleme değildi, korkuydu.

Tasarımcı masaya ne getiriyor

Büyük ölçekli çözümlerin çoğu teknik yetersizlikten değil, insanların gerçek hayatına oturmadığı için tutmuyor. Tasarımcının katkısı burada üç yerde belirginleşiyor: farklı disiplinleri aynı masaya oturtmak, analizden çok senteze çalışmak ve fikri erken bir aşamada denenebilir bir şeye dönüştürmek. Çözümün üretildiği yer ile kullanıldığı yer arasındaki mesafe ne kadar kısaysa, tahmin payı o kadar azalıyor.

Topluluğu sürece dahil etmek bunun doğal uzantısı, fakat sınırı var. Bir topluluk kendi yaşadığı sıkıntıyı en iyi tarif eden taraftır; sıkıntının nereden doğduğunu görmek çoğu zaman dışarıdan, sistemin bütününe bakan birini gerektirir. Katılımcı yöntemleri semptomu doğru adlandırmak için kullanmak, kök nedeni ise ayrı bir analizle aramak daha sağlıklı çalışıyor.

Zincir değil, ağaç

Kök neden analizinin en bilinen aracı "5 Neden": bir belirtiden başlayıp ardışık olarak neden sorup derine iniyorsun. Yöntemin iki zayıf noktası var. Birincisi, tek bir nedensel zincir varsaydığı için ilk adımda hangi dalı seçtiysen beşinci adımda o dalın ucundasın, komşu dalları hiç görmemiş olursun. İkincisi, durma noktasını sayı belirlemez; beşinci neden derin bir felsefi tespit de olabilir, elinde kalan tek şey odur ve onunla yapabileceğin hiçbir şey yoktur.

Kök neden aramaya ben genelde soru zinciriyle değil, nedenleri dallandıran basit bir ağaç çizerek başlarım; aynı belirtiyi besleyen iki ayrı neden varsa zincir yöntemi bunlardan birini sessizce eler. Durma ölçütü de sayı değil, elde eyleme dönüştürülebilir bir neden kalması.

Havacılık kaza soruşturmaları bunun olgun örneği. Rapor "pilot hatası" der ve orada durursa hiçbir şey değişmez; soruşturmalar bunun yerine eğitimden bakım prosedürlerine, kokpit iletişim kurallarından vardiya planlamasına kadar üst üste binmiş katmanlara bakar. Kaza tek bir hatanın değil, aynı anda hizalanan birkaç eksikliğin sonucudur.

Sistemi görmek

Sistemsel düşünme, tasarımcının ekonomiden pazarlamaya kadar her alanda uzman olması demek değil; kararının başka yerde ne tetiklediğini görebilecek kadar bilmesi demek. Buradaki en somut kural şu: darboğazın dışındaki bir adımı hızlandırmak sistemi hızlandırmaz, sadece darboğazın önünde bekleyen yığını büyütür. Kendi ekranını iki kat hızlandıran ekip, işin onay bekleyen tarafına dokunmadığı sürece toplam süreyi değiştirmemiş olur.

Aynı mantık organizasyona da işliyor. Bir departmanın kendi metriğini optimize etmesi, komşu departmanın işini zorlaştırıyorsa şirket net olarak geri gitmiştir. Bütünü gören tasarımcının değeri de tam burada: hangi parçanın iyileştirilmesinin gerçekten fark yarattığını, hangisinin sadece rakam güzelleştirdiğini ayırt edebilmesi.

Pratikte başlangıç noktası mütevazı: elindeki problemin belirtisini bir cümleyle yaz, sonra o cümleyi doğuran nedenleri dallandır, en az iki dalın ucunda somut bir müdahale bulana kadar dur. Bu adımı atlayıp doğrudan çözüm eskizine geçen ekiplerin çoğu, sonradan aynı problemi ikinci kez çözüyor.