POV ve How Might We ile Tasarım Problemini Çerçevelemek

Tasarım odaklı düşünmede fikirlerin kalitesini belirleyen şey beyin fırtınasının süresi değil, o odaya girerken elde ne olduğudur. Problem cümlesi bulanıksa çıkan fikirler de bulanık olur. POV ve How Might We, o cümleyi çalışır hale getiren iki basit araç.

POV: kullanıcı, ihtiyaç, içgörü

Point of View, çözülecek problemi tek bir kullanıcıya ve onun tek bir ihtiyacına indirger. Şablonu kısa: [Kullanıcı] ... [fiil hâlinde ihtiyaç] duyuyor, çünkü [içgörü].

Üç parçanın da ayrı bir işi var. Kullanıcı kısmı “herkes” olamaz; herkes için tasarlanan şey kimse için tasarlanmamış olur. İhtiyacın fiil hâlinde yazılması gerekir, çünkü isim hâlinde yazılan ihtiyaç çoğu zaman gizli bir çözümdür: “kullanıcının bir filtre paneline ihtiyacı var” bir ihtiyaç değil, kılık değiştirmiş bir taleptir. İçgörü ise ihtiyacın nedenini taşır ve fikir aşamasında asıl yol gösteren odur.

POV cümlesini tek satırda tutarım. İki satıra taşıyorsa içinde iki ayrı problem vardır ve o ikisini ayırmadan devam etmek sonraki her aşamada iki yöne birden çekiştirir.

How Might We: tespitten davete

POV bir tespittir, HMW ise davet. “How” henüz çözümün bilinmediğini kabul eder, “might” birden fazla cevabın mümkün olduğunu söyler, “we” işi ortak alan hâline getirir. Kırsalda yaşayan ebeveynlerin prematüre bebeklerini sıcak tutma ihtiyacı bir POV’dur; “Evde kullanılabilen, uygun maliyetli bir ısıtıcıyı nasıl tasarlayabiliriz?” ondan çıkan HMW’dir.

Sorunun genişliğini ölçmenin iki yolu

“Çok dar olmasın, çok geniş de olmasın” tavsiyesi tek başına işe yaramaz, çünkü ölçüsü yok. İki test bu boşluğu kapatıyor:

• Soruyu mevcut bir ürünün adıyla cevaplayabiliyorsanız çok dardır. “Nasıl bir kaydırmalı filtre ekleriz?” zaten cevabını içeriyor.
• POV’daki kullanıcıyı bambaşka biriyle değiştirdiğinizde soru hâlâ aynı anlama geliyorsa çok geniştir. “İnsanların hayatını nasıl kolaylaştırabiliriz?” her yere uyar, hiçbir yeri işaret etmez.

Soru sayısını çoğaltmanın sessiz maliyeti

Sık verilen “her POV için 5-10 HMW yazın” tavsiyesi kâğıt üzerinde zararsız görünür. Dört POV ve her birine sekiz soru otuz iki başlık eder; her başlığa on dakika ayıran bir atölye beş saati aşar. Üretim aşamasında bolluk doğru, fakat o listeyi ekibin önüne getirmeden önce eleyin. Elemeyi yapmazsanız atölyenin ilk yarım saati soru okumakla geçer ve enerji en verimli olduğu anda tükenir.

Tekrarlanan üç hata

Birincisi teknik detaya erken geçmek. Veri modeli ya da ekran akışı konuşulmaya başlandığı anda problem tanımı fiilen kapanmıştır. İkincisi çözümü brief’in içine gömmek; “şu ekrana bir sihirbaz ekleyelim” diye başlayan bir brief tasarımcıdan fikir değil onay ister. Üçüncüsü POV’u araştırma yapmadan masa başında yazmak: uydurulmuş bir içgörü, sonraki bütün fikirleri kendi hatası etrafında toplar.

POV sabit bir metin değildir

Süreç ilerledikçe kullanıcı hakkında bildiğiniz şey değişir. Prototipten dönen ilk geri bildirim çoğu zaman içgörünün yanlış olduğunu gösterir ve cümleyi güncellemek geri adım değil, sürecin çalıştığının işaretidir. Baştan sona değişmeden kalan bir POV ya problemi ilk seferde tam isabetle bulduğunuz ya da hiç test etmediğiniz anlamına gelir. İkincisi çok daha olası.