How Might We Soruları Nasıl Yazılır: Genişlik ve Ölçülebilirlik
Çoğu beyin fırtınası oturumu kötü bir soruyla başlar. HMW kalıbı tam bu yüzden tutuyor: problemi fırsat alanına çevirirken cevabı peşinen söylemez. Ama kalıbın kendisi iyi soru üretmiyor, soruyu nasıl kurduğunuz üretiyor.
Soru, içgörüden sonra gelir
Yazmaya oturduğunuzda elinizde ham şikâyet değil bir içgörü olmalı. “Kullanıcılar ürünün tüm özelliklerinden habersiz” cümlesi içgörü gibi görünür, oysa tartışmalı bir öncül taşır: kullanıcı neden tüm özellikleri bilmek zorunda? Yanlış öncülün üstüne kurulan soru, ne kadar güzel yazılsa da yanlış yere fikir üretir.
Şikâyeti içgörüye çevirmenin kısa yolu, cümleyi “çünkü” ile bitirmeye çalışmaktır. “Başvuru süreci kafa karıştırıcı, çünkü kullanıcı hangi belgenin gerektiğini ancak son adımda görüyor.” Artık sorulacak bir şey var.
Çözümü soruya gizlemeyin
“Nasıl daha az soruyla başvuruyu tamamlatabiliriz?” açık uçlu görünür, değildir. Cevabı içinde: formu kısaltmak. Oturum boyunca ekip tek bir çözüm dalında gezinir, geri kalan ihtimaller hiç konuşulmaz.
Çoğu zaman fiile bakmak yeter. “Gösterebiliriz”, “ekleyebiliriz”, “bildirebiliriz” bir uygulama yolunun adıdır. “Farkına varabilir”, “tamamlayabilir”, “bulabilir” ise sonucu tarif eder, yöntemi serbest bırakır.
Genişlik ayarı ölçülebilirlikle yapılır
Bir HMW sorusunu tahtaya yazmadan önce genelde tek soruyla sınarım: bu soru iyi cevaplanırsa hangi sayı değişir? Cevabı veremiyorsam soru fazla geniştir, oturumdan çıkan fikirler de ölçülemez olur.
Bu test, dolaşımdaki “iyi HMW” örneklerinin bir kısmını eler. “Nasıl başvuru sürecinde kullanıcıların kendini daha güvende ve rahat hissetmesini sağlayabiliriz?” sorusu yeterince geniş olduğu için iyi sayılıyor, ama karşılığı olan bir sayı yok. Dar soru ekibi tek çözüme hapsediyorsa, ölçüsüz geniş soru da oturumu kimsenin yanlış diyemeyeceği fikirlerle doldurur. Aradaki bandı tutmak gerekiyor:
| İçgörü | Sorunlu HMW | Çalışan HMW | Takip edilecek ölçü |
|---|---|---|---|
| Kullanıcı ihtiyacı olan özelliği, ihtiyaç doğduğu anda bulamıyor. | Nasıl kullanıcıya tüm özellikleri gösterebiliriz? (çözümü söylüyor) | Nasıl kullanıcı aradığı işi yapan özelliği ilk denemesinde bulabilir? | Aramadan sonra vazgeçme oranı |
| Gerekli belgeler ancak son adımda görünüyor. | Nasıl kullanıcıların kendini daha güvende hissetmesini sağlayabiliriz? (ölçüsü yok) | Nasıl kullanıcı başvuruya başlamadan neyin gerekli olduğunu bilebilir? | Son adımda yarıda bırakma oranı |
Pozitif yazma kuralının sınırı
Negatif kurulmuş bir soru (“Nasıl hataları azaltabiliriz?”) mevcut durumu referans alır, fikirler de mevcut durumu rötuşlamak etrafında döner. Pozitif kurulan soru hedef durumu referans aldığı için daha uzağa bakılmasına izin verir. Kazanç buradan gelir, moralden değil.
Kural kelime oyununa dönerse işe yaramaz. “Daha az hata” yerine “daha güvenli” yazmak hedefi netleştirmiyorsa elinizde yalnızca daha hoş duran aynı soru vardır.
Oturumdan otuz soru çıkınca
Altı kişilik ekibin her üyesi beşer soru yazarsa tahtada otuz soru olur. Bunları ikili karşılaştırarak elemeye çalışmak işlemez: otuz sorunun ikili karşılaştırma sayısı 30×29/2, yani 435. Ekibin enerjisi ikinci saatte, hâlâ ilk kümedeyken biter.
Pratikte yürüyen sıra şu: benzer soruları temaya göre kümeleyin, her kümeyi tek bir soru olarak yeniden yazın, sonra kişi başı üç oyla önceliklendirin. Kümeleme karşılaştırma işi değil dağıtma işidir, o yüzden otuz not yarım saatte beş altı temaya iner. Beyin fırtınasına bir temayla girin, en fazla iki.
Elenen sorular silinmez, bir kenara yazılır. Bir sonraki döngüde sıra onlara gelir ve aynı içgörüyü ikinci kez keşfetmek zorunda kalmazsınız.