Tasarım Kararını Hikayeyle Savunmak
Bir tasarım kararını savunmanın iki yolu var: bulguyu tablo olarak göstermek ya da onu yaşayan birinin hikayesi olarak anlatmak. İkincisi daha hızlı ikna eder, ama tek başına kullanıldığında en basit itiraza bile dayanmaz. İşe yarayan kurgu, hikayeyi verinin yerine değil önüne koymaktır.
Hikaye veriyi taşır, yerine geçmez
Sunumdaki “kullanıcılar ödeme adımında zorlanıyor” cümlesi kimseyi yerinden kaldırmaz. Bir katılımcının kart bilgisini üçüncü kez girip vazgeçtiği otuz saniyelik kayıt kaldırır. Aradaki fark bilginin doğruluğunda değil, salonda kalma süresinde.
Ama anlatının arkasında iz bırakın: her hikayenin yanına hangi oturumdan, kaçıncı katılımcıdan, hangi görevden geldiğini yazın. “Kaç kişide gördünüz” sorusu her toplantıda gelir, cevabı slaytta hazır değilse anlatı anekdota düşer ve karar bir sonraki toplantıya ertelenir.
Tek alıntıdan yaygınlık iddiası çıkmaz
Beş kullanıcıyla yapılan testin sorunların yaklaşık %85’ini bulduğu iddiası, her katılımcının tek bir sorunu yakalama olasılığını 0,31 kabul eden 1-(1-0,31)^5 hesabına dayanır. Hesap bir sorunun en az bir kez görülme ihtimalini verir. Ne sıklıkta yaşandığını değil.
Pratikteki karşılığı şu: beş kişilik bir oturumda tek katılımcıda çıkan davranış, o sorunun var olduğunu gösterir, yaygın olduğunu göstermez. Hikayeyi “kullanıcılar şunu yapıyor” diye anlattığınızda bu ikisini karıştırmış olursunuz ve ilk itirazda anlatının tamamı elinizde kalır. “Bu sorun bir katılımcıda net biçimde ortaya çıktı, tekrar sıklığını ölçmedik” cümlesi kulağa daha zayıf gelir, ama ayakta kalır.
Yaygınlığı gerçekten iddia edecekseniz kaynak test değildir. Adım bazlı düşüş oranı, hata logu, destek kayıtları bunun için var. Hikaye sorunun varlığını gösterir, sayı büyüklüğünü ölçer; ikisini aynı slaytta ayrı ayrı gösterin.
Dinleyiciye göre nereden başlayacağınızı seçin
Aynı bulgu, kime anlatıldığına göre farklı yerden açılır. Ürün tarafına hikayeyi kullanıcının vazgeçtiği andan başlatın, çünkü orada bir dönüşüm kaybı var. Geliştirme ekibine aynı hikayeyi kullanıcının tetiklediği hatadan başlatın, çünkü orada düzeltilecek somut bir davranış var. Bütçeyi tutan kişiye süre ve tekrar sayısı üzerinden gidin.
Terminoloji de aynı mantıkla değişir. Sahadaki bir operatöre bilişsel yükten bahsetmeyin; vardiyanın sonunda o ekranda iki kez yanlış tuşa basıldığını söyleyin. Aynı bulgu, karşılığı olan kelimeyle.
Storyboard ve yolculuk haritası ne zaman gerekir
Görsel belge üretmek ucuz değil, o yüzden gerekçesi olsun. Yolculuk haritası, sorun tek ekranda değil ekranlar arasındaki geçişte olduğunda karşılığını verir; tek bir formun alan sırasını tartışıyorsanız harita çizmek zaman kaybı. Storyboard ise ürünün kullanıldığı fiziksel bağlam kararı etkiliyorsa gerekir. Ayakta, eldivenle, güneş altında kullanılan bir arayüzü anlatmanın başka yolu yok.
Kalan durumlarda ekran kaydından kesilmiş otuz saniye, iki gün emek verilmiş bir haritadan daha çok iş görüyor.
Toplantı bittikten sonrası
Anlatının hedefi kararın alınması değil, kararın izlenebilir kalması. Toplantıdan sonra tek paragraflık bir not gönderin: hangi hikaye anlatıldı, hangi karar çıktı, kim ne yapacak. İki ay sonra “bunu neden böyle yapmıştık” sorusu geldiğinde elinizde slayt değil o not olacak.