Tasarım Odaklı Düşünmede Problemi Tanımlama
Empati aşaması bittiğinde elinizde bir yığın not, alıntı ve gözlem olur. Toplamak kolay kısımdı. Asıl iş, o yığından ekibin üzerinde çalışabileceği tek bir cümle çıkarmak; tasarım odaklı düşünmenin ikinci aşaması da tam olarak bu dönüşümün adı.
Analiz ile sentez sırayla değil, dönüşümlü çalışır
Analiz, elinizdeki karmaşayı parçalarına ayırmak. Sentez, o parçaları yeni bir bütün olarak birleştirmek. Kitaplarda ayrı adımlar gibi dururlar ama pratikte bir öğleden sonra içinde birbirini üç kez kovalar: notları ayırırsınız, bir örüntü görüp gruplarsınız, grup tutmayınca açıp yeniden ayırırsınız. Problemi tanımlama aşaması bu gidip gelmenin kendisidir, sonunda ulaşılan temiz bir çıktı değil.
Notları duvara serip gruplamak
Görüşme notları, saha gözlemleri, fotoğraflar ve akılda kalan cümleler önce tek bir yüzeye çıkar. Duvar da olur, Miro panosu da. Amaç hepsini aynı anda görebilmek, çünkü ilişkiler ancak yan yana durunca görünür.
İki şey bu adımı belirgin biçimde kolaylaştırıyor. Birincisi, her notta tek bir fikir bulunması: iki fikir sığdırdığınız notu ikiye bölün, yoksa o not iki gruba birden ait olmak ister ve gruplamayı kilitler. İkincisi, grup başlıklarını önceden koymamak. Başlıkla başlarsanız notları başlığa uydurursunuz; önce yığınlar oluşur, ad sonra gelir.
Gruplama işi tamamlandığında beş ila yedi arası küme kalmasını hedefliyorum. Yirmi küme çıkıyorsa gruplama değil, etiketleme yapılmıştır. Tek bir dev küme çıkıyorsa da ayrım kriteri fazla soyut seçilmiştir.
POV cümlesi ve çünkü tuzağı
POV, problemi üç parçaya bölen bir kalıp: kullanıcı, ihtiyaç, içgörü. Yaygın bir örnek şöyle kurulur: Engelli bir öğrenci bilgiye kolayca erişmek istiyor, çünkü mevcut dijital kaynaklar erişilebilir değil.
Bu cümlenin son parçası içgörü değil. İhtiyacın olumsuz halde tekrarı. Erişmek istiyor, çünkü erişemiyor. Kalıp doldurulmuş ama yeni bilgi eklenmemiş.
Basit bir test var: çünkü sonrasını okuyun ve ihtiyacı zihninizden silin. Geriye ihtiyaçtan bağımsız bir bilgi kalıyor mu? Kalmıyorsa içgörü yok demektir. Aynı cümlenin çalışan hali şöyle görünür: Engelli bir öğrenci ders materyaline kendi başına erişmek istiyor, çünkü her materyal için bir başkasından yardım istemek onu sınıfın gerisinde bırakıyor. Bu versiyon çözüm alanını da açar; ortada erişilebilir PDF üretmek dışında, yardım isteme zorunluluğunu ortadan kaldıran başka yollar da olduğu görünür hale gelir.
Tanımı bir fiille kurmak da işe yarıyor. Oluştur, uyarla, kaldır gibi. İsim yığınıyla yazılmış tanımlar rapor gibi okunur, fiille yazılanlar ekibi harekete davet eder.
Dar mı geniş mi sorusunun cevabı POV cümlesinde değil
İyi bir problem tanımının yaratıcılığa alan bırakacak kadar geniş, yönetilebilecek kadar dar olması istenir. İki talep tek cümleye yüklenince cümle kırılır: ya bir çözümü gizlice içeri sokan bir tanım çıkar ya da herkesin altını imzalayabileceği kadar boş bir tanım.
Ayrımı yapmak daha sağlıklı. POV dar olsun, tek kullanıcı ve tek içgörü taşısın. Genişliği How Might We sorularında üretin. Bir POV cümlesinden on HMW sorusu çıkar, birkaçı saçma olur, sorun değil.
HMW yazarken tek gerçek hata soruyu POV kadar somut tutmamaktır. "Bilgiye erişimi nasıl kolaylaştırabiliriz?" sorusu her fikre evet dediği için hiçbirine yön vermez. Soruyu POV cümlesinin tek bir parçasına bağlayın: "Materyali dönüştürme işini öğrencinin kendi telefonuna nasıl taşıyabiliriz?" Bu soru dar görünür ama altında yirmi farklı çözüm var.
Neden-nasıl merdiveninde ne zaman durulur
Bir ihtiyaca neden diye sormak sizi soyuta, nasıl diye sormak somuta götürür. Merdiven fikri güzel, eksik olan kısım nerede duracağınız.
Yukarı doğru gitmenin sonu her zaman aynı yere çıkar: insanlar zaman kazanmak, güvende hissetmek, saygı görmek ister. Buraya vardıysanız bir basamak fazla çıkmışsınız ve elinizde artık bir tasarım problemi değil, bir insanlık durumu var.
Kullandığım durma kuralı şu: bir üst basamak, bu ekibin bu çeyrekte değiştirebileceği bir şeyi tarif etmiyorsa bir alt basamağa dönün ve tanım olarak orayı alın. Aşağı inerken de aynı kural ters yönde çalışır. Basamak tek bir çözümü tarif etmeye başladıysa çok inmişsiniz demektir; "ekran okuyucu uyumlu PDF üretelim" bir problem tanımı değil, zaten verilmiş bir karardır.
Kaynak