Kullanılabilirlik Testi: Araştırma Hedefini Senaryoya Çevirmek

Kullanılabilirlik testinin zor kısmı oturumu yürütmek değil, oturumda neyin sorulacağına karar vermek. Elinizde yirmi ekranlık bir ürün, birkaç paydaş endişesi ve kırk beş dakika var. Araştırma hedefinden katılımcının eline verilen senaryo metnine kadar giden yol, aslında bu üçünü birbirine sığdırma işi.

Görev listesi kayıttan çıkar, toplantıdan değil

Neyin test edileceğini belirlemenin iki yolu var: ekibe sormak ve kayda bakmak. Kayıt tarafında arama kutusuna yazılanlar, en çok girilen sayfalar, destek talebi açılan konular duruyor. Bunlar kullanıcının yaptığı şeyin izi. Paydaş görüşmesi ise ekibin neyi merak ettiğinin izi, ki o da değerli ama farklı bir veri. İkisine de bakarım, yine de destek kayıtlarını paydaş görüşmelerinden daha güvenilir bulurum: biri gerçekleşmiş bir başarısızlığı anlatır, diğeri olabilecek bir başarısızlığı tahmin eder.

Bir e-ticaret sitesinde herkesin aklına ilk gelen görev sepete ekleme ve ödeme olur. Destek kayıtlarına bakınca yığılma çoğu zaman başka yerdedir: kargo takibi, iade başlatma, fatura bilgisini değiştirme. Test edilecek görev listesini oradan kurmak, ürünün en çok konuşulan akışını değil en çok acıtan akışını masaya getirir.

Önceliklendirme konsensüs arama değildir

Yaygın tavsiye şöyle: konuları kartlara yazın, ekiple puanlayın, ortalamayı alın. Bu yöntem sorunların kullanıcıya etkisini değil, odadaki kişilerin kendi alanlarına verdiği ağırlığı ölçer. Ekip puanlaması, yalnızca her puanın arkasında bir sayı varsa işe yarar.

İki eksen yeter: sorun ne sıklıkla yaşanıyor ve yaşandığında neye mal oluyor. Sıklık için analitik ya da destek hacmi, maliyet için terk oranı veya o konuda açılan talebin ortalama çözüm süresi kullanılabilir. Nadir ama satın almayı tamamen durduran bir hata, sık ama kullanıcının kendi başına atlattığı bir pürüzden önce gelir.

Problemi bir cümleye indir, sonra soruya çevir

Önceliklendirilmiş her konu tek cümlelik bir problem tanımına dönüşmeli. Örnek: kullanıcılar ürün kurulum talimatlarını bulamıyor, bu yüzden çağrı merkezine yükleniyorlar. Cümlede hem kullanıcının tıkandığı yer hem de bunun şirkete bedeli duruyor.

Araştırma hedefleri bu cümlenin açtığı sorulardır:

• Kullanıcı talimata tam olarak hangi anda ihtiyaç duyuyor?
• Aradığı yerde olmadığında ikinci olarak nereye bakıyor?
• Vazgeçip destek araması yapmaya ne kadar sonra karar veriyor?

Her sorunun yanına oturumda neyi gözleyeceğinizi de yazın. Üçüncü soru için bu, sayaca bakmak demek: kullanıcı yardım istemeden önce kaç ekran gezdi. Başarı ölçütünü oturumdan önce yazmazsanız, kayıtları izlerken herkes kendi beklediği sonucu görür.

Senaryo, görev listesi değil durum anlatır

Katılımcıya verilen metin, arayüzün adlarından arınmış olmalı. Buton adı geçtiği anda test, kullanıcının yolu bulup bulamadığını değil, talimatı takip edip edemediğini ölçmeye başlar.

Zayıf senaryo: ürün sayfasındaki Kurulum sekmesine gidip PDF'i indirin. Çalışan senaryo: cihazı yeni aldınız, kutuyu açtınız, kabloyu nereye takacağınızı bilmiyorsunuz. İkinci metin kullanıcıyı kendi motivasyonuyla hareket ettirir ve yolu seçmeyi ona bırakır. Senaryo birden fazla araştırma hedefini kapsayabilir, ama tek bir senaryoda üç farklı akışı birleştirmeye çalışırsanız katılımcı hangi noktada tıkandığı belirsizleşir.

Oturum süresi listeyi sizin yerinize kısaltır

Yukarıdaki hat sürekli genişleyen bir liste üretir: görevler, endişeler, problem tanımları, her tanım için birkaç hedef, her hedef için gözlenecek davranışlar. Oturum ise sabit bir kutu. Sesli düşünmeyle çalışan bir senaryo pratikte 7 ila 10 dakika sürüyor; başa giriş ve ısınma, sona kapanış sorularını koyduğunuzda 45 dakikalık bir oturumda dört senaryo kalır, iyimser durumda beş.

Yani önceliklendirme adımının görevi listeyi önemliden önemsize sıralamak değil, dörde indirmek. Geri kalanı sonraki tura yazın. Senaryoları yazdıktan sonra tek bir pilot oturum yapın: metin anlaşılmıyorsa ya da süre taşıyorsa bunu dört katılımcı harcamadan önce görmüş olursunuz.