Kullanılabilirlik Testinde Beş Kullanıcı Ne Zaman Yetmez
Kullanılabilirlik testinin zor kısmı oturumu yapmak değil, bulguyu ürüne geçirmek. Çoğu ekip testi düzenli yapıyor, raporu da yazıyor, sonra rapor sırada bekleye bekleye tazeliğini kaybediyor. Tıkanma genelde iki yerde: bulgunun kime ne hızda ulaştığı, bir de kaç kullanıcının yeteceği sorusunun fazla kolay cevaplanması.
“Beş kullanıcı yeter” nereden geliyor, nerede bozuluyor
Rakam havadan gelmiyor. Nielsen ve Landauer’ın 1993’te önerdiği modelde bulunan sorun oranı 1-(1-L)^n biçiminde ilerler: L tek bir kullanıcının belirli bir sorunu yakalama olasılığı, n de kullanıcı sayısı. L=0,31 alındığında beş kullanıcı sorunların yaklaşık %85’ini açığa çıkarır, yaygın olarak alıntılanan rakam da budur.
Peki ya L bu kadar yüksek değilse? Uzmanlık gerektiren, yoğun bir arayüzde tek kullanıcının belirli bir sorunu yakalama olasılığı rahatlıkla 0,10’a iner. Aynı formül o zaman beş kullanıcı için %41 veriyor, yani yarısından azı. Peki ya kitle tek parça değilse? İki ayrı segmentiniz varsa (diyelim son kullanıcı ve yönetici rolü) beş kişi toplamda değil segment başına gerekir; karışık bir beşli iki grubu da yarım yamalak temsil eder.
Yani beş sayısı iki varsayım taşıyor: homojen bir kullanıcı grubu, ve sorunların görece kolay yakalandığı bir arayüz. İkisi de sağlanıyorsa beş kişi gerçekten yeter ve büyük çalışmalardan çok daha hızlı sonuç verir.
Hangi yöntem hangi soruya
Sezgisel değerlendirme, uzmanın arayüzü ilkeler üzerinden taramasıdır; ucuzdur, hızlıdır, katılımcı bulmayı gerektirmez. Karşılığında öğrettiği şey sınırlı: uzman nerede zorlanılacağını tahmin eder, gerçek kullanıcının nerede zorlandığını göstermez. Bilişsel yürüyüş belirli bir görevi adım adım izler ve “kullanıcı bu adımda ne yapması gerektiğini anlıyor mu” sorusuna odaklanır; henüz test edilecek bir ürün yokken, yeni bir akış kurgulanırken en verimlisi bu.
Gözlem testi bunların yerine geçmez, sıradan sonra gelir. Uzman taraması ve yürüyüş bariz sorunları temizler, gözlem testi asıl sürprizleri açığa çıkarır. Sıra tersine dönerse beş kullanıcının değerli oturumları, uzmanın on dakikada yakalayacağı hataları bulmakla harcanır.
Bulgunun ürüne ulaşması
Sonuçları yazılı raporla aktarmayı genelde ikinci sıraya koyarım; en iyi aktarım geliştiricinin oturumu kendi gözüyle izlemesi. Kullanıcının aynı düğmeyi üç kez farklı yerde araması, rapordaki “gezinme etiketleri belirsiz” cümlesinden fazlasını anlatır ve tartışmayı bitirir.
Rapor yine de gerekli, ama çoğu ekip bulguları sadece ciddiyete göre sıralıyor. Uygulama maliyetini yanına koymak listeyi çok daha kullanışlı yapıyor: etiket metni değişikliğiyle veri modeline dokunan bir akış değişikliği aynı satırda eşit görünür, oysa biri aynı gün çıkar, diğeri bir sprint ister. İki sütun yeter, tahmini etki ve tahmini maliyet.
Bir de zamanlama var. Bulgu, oturumdan bir iki gün sonra tasarım ekibinde olmalı; gecikince ekip başka işe geçmiş oluyor ve kayıt izlemek yeniden maliyet doğuruyor.
Katılımcı bulmak ve tekrarlamak
Küçük ekiplerin asıl darboğazı yöntem değil katılımcı. Kurumsal tarafta hazır kullanıcı havuzu varken, küçük bir projede beş kişiyi aynı hafta bir araya getirmek başlı başına iş. Peki ya beklemek yerine turu küçültseniz? Beş kişilik tek bir oturum yerine iki kişilik üç turu ikişer hafta arayla yapmak çoğu durumda daha iyi sonuç veriyor, çünkü her turdan sonra düzeltme şansı doğuyor ve sonraki tur bir önceki turun düzeltmesini sınıyor.
Katılımcıyı motive etmek için büyük bütçe gerekmiyor, ama karşılıksız da olmuyor; küçük bir hediye ya da ürünün ücretli bir özelliğine süreli erişim, iptal oranını gözle görülür biçimde düşürüyor.