Kritik Olay Tekniği: Ne Gösterir, Neyi Kaçırır
Kritik Olay Tekniği kullanıcıdan genel bir değerlendirme istemez, tek bir olayın anlatısını ister: ne oldu, ne yaptınız, sonuç ne oldu. Yöntemin gücü de sınırı da aynı yerden çıkıyor. Uçlarda olan biteni ayrıntısıyla görürsünüz, ortada olan biteni hiç görmezsiniz.
Bir olayı kritik yapan ne?
Yöntemi 1950'lerde John Flanagan pilot eğitiminde başarı ve başarısızlık nedenlerini ayıklamak için kurmuştu; insan-bilgisayar etkileşimine oradan geçti. Ölçüt bugün de aynı: katılımcı, anlattığı olayın sonucu doğrudan etkilediğine inanıyorsa o olay kritiktir.
Burada dikkat çeken bir şey var. Kritikliğe karar veren araştırmacı değil, katılımcı. Yani elinizdeki veri "ne oldu" değil, "kullanıcının neyi belirleyici saydığı". Peki kullanıcının önemsiz bulup atladığı, ama akış üzerinde asıl etkiyi yaratan adımlar ne olacak? Onlar CIT'e hiç girmez. Yöntemi seçerken kabul ettiğiniz ilk takas bu.
Soruyu kurmak
Toplanan verinin kalitesi neredeyse tamamen soruya bağlı. Üç şey işe yarıyor:
- Zamanı sınırlayın. "Geçmişte yaşadığınız bir zorluk" yerine "son iki hafta içinde". Uzayan aralıkta anlatılan şey hatıra değil, yeniden kurgu olur.
- Olumlu ve olumsuz olayı ayrı ayrı sorun, üstelik bu sırayla. Tersi olduğunda görüşmenin geri kalanı şikâyet tonuna yerleşiyor.
- Sonucu sorun. Olay anlatısı "sonra ne yaptınız" ile bitmezse elinizde his kalır, davranış kalmaz.
Kullanışlı bir kalıp: "Son iki haftada ürünü kullanırken işinizi belirgin biçimde kolaylaştıran ya da tıkayan bir anı anlatır mısınız? O anda ne yapmıştınız, sonuç ne oldu?"
Yöntemin göremediği
CIT'in en sık yapılan hatası bulguları sayıya çevirmek. Bunu yapamazsınız, çünkü paydanız yok: yalnızca hatırlanmaya değer bulunan olaylar anlatıldı, tipik kullanım hiç raporlanmadı. On beş kişiden altısının aynı tıkanmayı anlatması "kullanıcıların %40'ı bu sorunu yaşıyor" demek değil, "bu tıkanma anlatılacak kadar can yakıyor" demek. İkincisi de değerli bir bilgi, ama başka bir bilgi.
Peki sıklık gerçekten gerekiyorsa? O zaman CIT tek başına yetmez; hangi olayın ne kadar yaygın olduğunu ölçmek için ya davranış verisine ya da temsili bir ankete geçmek gerekir. CIT o anketin sorularını üretmek için iyi bir başlangıç.
Anlatıyı olay kaydıyla eşleştirmek
Görüşmeden çıkan cümle çoğu zaman şuna benziyor: "Kaydetmeye çalıştım, olmadı, baştan başladım." Bu haliyle bir arayüz iddiası, henüz kanıt değil. Bir CIT bulgusunu doğrudan yol haritasına bağlamam; önce o anın oturum kaydında ya da hata günlüğünde karşılığı var mı diye bakarım. Karşılığı varsa elinizde artık hem neden hem ne olduğu var, üstelik hangi sürümde başladığı da genellikle çıkıyor. Karşılığı yoksa daha ilginç bir durum var demektir: kullanıcı sistemin hata saymadığı bir şeyi başarısızlık olarak yaşamış.
Bunun için gereken alt yapı da abartılacak bir şey değil. Olay anlatısında geçen ekranı ve zaman aralığını kayıtta aramak, çoğu üründe zaten var olan telemetriyle yapılabilir.
Kodlama maliyeti
Toplanan olaylar temalara ayrılırken iş asıl burada büyüyor. Otuz görüşmeden yüzü aşkın olay çıkabiliyor ve her biri okunup etiketleniyor. İki pratik önlem: kod setini ilk on olaydan sonra dondurup geri kalanına aynı setle bakın, bir de örneklemin bir kısmını iki kişiye bağımsız kodlatıp ayrıştığınız yerleri konuşun. Ayrışma oranı yüksekse sorun kodlayıcıda değil, tanımların gevşekliğindedir.
CIT'i özel yapan şey de zaten kategori tablosu değil. Kullanıcının kendi cümleleriyle anlattığı, tarihi ve sonucu belli olan tek bir an, hiçbir memnuniyet ölçeğinin veremeyeceği kadar net bir tasarım girdisi veriyor.