UX Case Study'de Süreç Bölümü: Adımları Değil Kararları Yaz

Süreç bölümü, bir UX case study'nin gerçekten okunan tek yeri olabilir. Orada aranan şey ekran görüntüsü değil, hangi kararın neye dayanarak verildiği. Aşama isimlerini sıralamak bunu göstermez; tek bir karar anını açıp içindeki gerekçeyi çıkarmak gösterir.

Okuyan kişi ne arıyor?

Case study'yi açan kişinin kafasındaki soru “bu insan hangi adımları biliyor” değil. Soru şu: belirsiz bir durumda ne yaptı. Empati, tanımlama, fikir üretimi, prototip, test başlıklarını herkes yazabilir; ayrım o başlıkların altında, hangi bilginin hangi kararı değiştirdiği anlatıldığında ortaya çıkar.

Basit bir kontrol var. Yazdığın her paragraf için sor: bu cümle silinse projeyi anlamam değişir mi? Değişmiyorsa süsleme yapıyorsundur.

Kararı yaz, adımı değil

“Kullanıcı görüşmeleri yaptım, bulguları yolculuk haritasına aktardım” cümlesi yapılan işi anlatır, verilen kararı anlatmaz. Kararı anlatan hali şuna benzer: sekiz görüşmenin altısında insanlar kayıt ekranında değil, kayıttan sonraki boş listede takıldı, bu yüzden formu kısaltmayı bıraktım ve boş ekrana örnek veri koydum.

Aradaki fark, ikinci cümlenin yanlışlanabilir olması. Okuyan kişi “ben olsam bunu başka yorumlardım” diyebilir. İlkine itiraz edilemez, çünkü bir iddia taşımaz.

Düz çizgi anlatısının inandırıcılık sorunu

Design Thinking'in beş adımı iyi bir anlatı iskeleti, kötü bir gerçeklik raporu. Projelerin çoğu geri döner: test sonucu problem tanımını bozar, tanım değişince araştırma sorusu da değişir. Süreci kesintisiz ilerleyen bir çizgi gibi sunmak okuyanda hafif bir şüphe bırakıyor, çünkü kendi projelerinin öyle gitmediğini biliyor.

Peki geri dönüşleri yazmak zayıf mı gösterir? Tersi oluyor. “İlk prototipte yanlış problemi çözdüğümü test sırasında anladım, tanımı yeniden yazdım” cümlesi üç ekran görüntüsünden daha fazla yetkinlik kanıtı taşır. Yanlış anlaşılan bir bulgu, kimsenin sormadığı bir soru, zaman yüzünden vazgeçilen bir çözüm: bunlar süreç bölümünün en okunası kısımları.

Artefakt sayısı üzerine iki çelişik tavsiye

Portfolyo rehberlerinde yan yana duran iki öğüt birbirini keser. Biri “her aşama için bir görsel koy” der, diğeri “az sayıda ama özenle seçilmiş artefakt kullan”. İkisini aynı anda uygulayamazsın; beş aşamanın beşine de görsel koyduğunda seçimi zaten yapmamış olursun. (Aynı sayfada ikisini birden öneren metinlerin çelişkiyi fark ettiğini sanmıyorum.)

Seçmek gerekiyor. Az artefakt, her birinin altında o görselin neyi değiştirdiğini söyleyen iki cümle. Persona kartının kendisi bir şey anlatmaz; “bu persona yüzünden şu özelliği listenin sonuna attım” anlatır.

Ekip işini bireysel katkıya çevirmek

“Takımla birlikte wireframe hazırladık” cümlesi kimin ne yaptığını gizler, okuyan da bunu fark eder. Kendi payını yazmak övünmek değil, bilgi vermek. Yaptığın iş araştırmayı yürütmek değil de görüşmelerde not tutmaksa onu yaz. Küçük ama net bir katkı, sınırı belirsiz büyük bir katkıdan daha güven verir.

Dışarıda bırakılacaklar

Case study bir proje raporu değil. Toplantı notları, kullanılan araçların listesi, kaç hafta sürdüğü sende kalsın. Yer açman gereken yerler: problemin neden problem olduğu, hangi bulgunun yönü değiştirdiği ve işin sonunda ne olduğu.

Sonuç ölçülmediyse ölçülmediğini yaz. Uydurulmuş bir “%30 arttı” cümlesi görüşmede sorulacak ilk soruyu davet eder ve orada dağılır. Ölçemediğin bir işi dürüstçe anlatmak, ölçtüğünü iddia edip açıklayamamaktan iyidir.