Pilot Testi Kendi Ekibinizle Yapmak

Pilot test, ürünü değil test planını denemektir. Katılımcının hedef kitleden olması bu yüzden şart değil; ölçülen şey senaryonun kendisi olduğu sürece ekipten biri çoğu zaman daha pratik bir seçimdir. Asıl mesele, ekip içi pilotun neyi doğru gösterdiğini neyi gizlediğinden ayırabilmek.

Pilotta denenen şey senaryodur

Bir pilot oturumun çıktısı kullanılabilirlik bulgusu değildir. Çıktı şudur: görev yönergesi anlaşıldı mı, kolaylaştırıcının soruları katılımcıyı yönlendiriyor mu, ekipman çalışıyor mu, oturum planlanan süreye sığıyor mu. Bunların hiçbiri için hedef kitleden bir katılımcıya ihtiyacınız yok. Yönergedeki bir cümle iki anlama geliyorsa, bunu sistemi bilen biri de fark eder.

Bu ayrımı baştan netleştirmek gerekiyor, çünkü pilotun en sık yapılan hatası buradan doğuyor: ekip arkadaşınız ekranda zorlandı diye tasarımı değiştirmek.

Ekipten kim uygun

Senaryoyu yazan kişi pilot katılımcısı olamaz. Kendi cümlenizdeki boşluğu okuyamazsınız, eksik olan kısmı zihniniz otomatik tamamlar. Aynı sebeple, test edilen ekranı kodlayan geliştirici de yönergeyi sınamak için kötü bir seçimdir; buna karşılık kurulum, kayıt, test ortamının veri durumu gibi teknik aksaklıkları en hızlı o yakalar. İkisini tek oturuma sıkıştırmayın.

Yönerge dilini sınamak içinse ürün ekibinin dışına çıkın. Destekten, muhasebeden, satıştan biri şirket içi terimleri bilir ama o ekranın iç mantığını bilmez. Aradığınız profil tam olarak budur.

Pilotun yanılttığı iki yer

Süre

Oturumu planlarken en çok işinize yarayan sayı süredir, ama pilottan çıkan süre olduğu gibi kullanılamaz. Ekipten bir katılımcı görevleri sistematik olarak daha hızlı bitirir; nereye tıklayacağını zaten biliyordur. Oturumu iki parçaya ayırın: karşılama, onam metni, kapanış soruları gibi sabit bölümler pilottan doğrudan aktarılır, çünkü onları katılımcı değil kolaylaştırıcı yürütür. Görev bölümü için pilotta ölçtüğünüz sürenin belirgin bir üstünü ayırın ve ilk gerçek oturumdan sonra bu payı kendi verinizle düzeltin.

Dil

Ekip içi katılımcı, yönergedeki şirket jargonunu görmez. Kayıt akışını tamamlayın cümlesi ona son derece açık gelir, çünkü "kayıt akışı" onun günlük kelimesidir. Dışarıdan gelen kişi aynı cümlede durur ve sorar. Pilotun bu parçasını atlarsanız, gerçek oturumda kaybettiğiniz ilk beş dakika yönergeyi açıklamakla geçer.

Etik metni de pilotta prova edilir

Katılımcıya "burada test edilen siz değilsiniz, tasarım" demek bir cümle değil, bir alışkanlıktır. Kolaylaştırıcının asıl zorlandığı yer o cümleyi söylemek değil, katılımcı tıkandığında susabilmek. Yardıma koşma refleksi oturumun verisini bozar ve bu refleksi ancak pratikle bastırırsınız. Ekip içi pilot bunun için ideal ortam: kimse gerçek bir katılımcıyı boşa harcamadan, kolaylaştırıcı sessiz kalmayı deneyebilir.

Onam, kayıt izni ve kapanış da aynı kapsamda. Kayıt izni isterken cümlenin yarısında tereddüt ediyorsanız bunu pilotta fark etmek, gerçek katılımcının karşısında fark etmekten iyidir.

Bulguları ikiye ayırın

Pilot sonunda elinizde iki farklı liste olmalı. Birincisi süreç listesi: yönerge düzeltmeleri, sıra değişiklikleri, süre ayarı, silinecek gereksiz görev. İkincisi teknik liste: çöken sayfa, kaydedilmeyen form, yanlış test verisi. Bu ikisi doğrudan uygulanır.

Üçüncü bir liste tutmayın. Ekip arkadaşınızın "bu buton bana ters geldi" yorumu kullanılabilirlik bulgusu değil, meslektaş görüşüdür; değerli olabilir ama test çıktısı olarak raporlanamaz. Aradaki farkı kayıt altına almazsanız, birkaç hafta sonra kimse o bulgunun nereden geldiğini hatırlamaz ve pilot verisi gerçek verinin içine karışır.

Son bir nokta: oturumda kimin hangi ekranda ne kadar kaldığını elle not tutmaya çalışmayın, kolaylaştırıcı zaten katılımcıyı dinliyor. Test ortamına koyacağınız birkaç satırlık bir zaman damgası kaydı bu işi görür, üçüncü parti bir analitik aracı kurmaya gerek yok.