Haftalık Kullanıcı Testinde Asıl Darboğaz: Düzeltme Hızı
Haftalık kullanıcı testi kulağa disiplinli bir ritüel gibi geliyor, ama zor kısmı testi yapmak değil. Her hafta yeni bulgu üretip çoğunu düzeltmeden bir sonrakine geçerseniz elinizde büyüyen bir liste ve değişmeyen bir arayüz kalır. Döngünün temposunu katılımcı sayısına göre değil, ekibin düzeltme hızına göre belirleyin.
Önce kapasiteyi hesaplayın
Kaba bir hesap yeterli. Her oturumda 4 kullanıcıyla çalışıp ortalama 8 bulgu çıkarıyorsanız, ekip de haftada 3 tanesini kapatabiliyorsa, dört hafta sonunda birikmiş 20 bulgunuz olur. Test sıklığını artırmak bu tabloyu düzeltmez, sadece listeyi daha hızlı şişirir.
İki çıkış yolu var. Ya kapsamı daraltıp haftada tek bir akışa bakarsınız, ya da testi iki haftada bire çekip aradaki haftayı tamamen düzeltmeye ayırırsınız. İkincisi, ekip küçükse ve aynı kişiler hem tasarlayıp hem kod yazıyorsa daha iyi çalışıyor.
Her oturumun tek bir sorusu olsun
Amaç tek cümleyle yazılamıyorsa oturum dağılır. "Ödeme adımında kart bilgisini kaç kişi ilk denemede tamamlıyor" iyi bir soru. "Kullanıcılar siteyi nasıl buluyor" kötü bir soru, çünkü cevabı bir oturuma sığmaz ve çıkan her şey aynı anda önemli görünür.
4-6 kişi bu ölçekte yeterli. Amaç istatistik üretmek değil, aynı yerde takılan üçüncü kişiyi görünce durup düzeltmek.
Bulguyu maliyetiyle birlikte yazın
Bir bulguyu düzeltme maliyetini bilmeden haftalık listeye almam. "Kullanıcı bu adımda kayboluyor" cümlesi tek başına bir iş değil: arkasında bazen 10 dakikalık metin değişikliği durur, bazen iki haftalık navigasyon yeniden kurgusu. Aynı satıra yazıldıklarında ikisi eşit görünüyor ve öncelik toplantısı bir tahmin yarışına dönüyor.
Bulguyu kaydederken üç şeyi yan yana koymak yeterli: kaç katılımcıda görüldü, kullanıcıyı durduruyor mu yoksa yavaşlatıyor mu, kodda karşılığı ne. Üçüncüsü genelde eksik yazılıyor ve tasarım tarafında ucuz görünen bir öneri, uygulamada tek bir bileşeni değil o bileşeni kullanan bütün ekranları etkiliyor.
Hızlı kazanılan örnekler
TiVo ekibinin haftalık test döngüsünden çıkan düzeltmeler bu ayrımı iyi gösteriyor: yanlış etiketlenmiş bağlantıların adları değişmiş, uzun açıklamalar kısa maddelere bölünmüş, satın alma akışının her adımına detaya giden iç bağlantılar eklenmiş. Üçü de küçük müdahaleler. Haftalık ritmin gerçek getirisi burada, mimariyi yeniden kurmakta değil.
Performans testi kullanıcı testi değildir
PageSpeed Insights, GTmetrix ve WebPageTest sayfanın ne kadar hızlı yüklendiğini söyler. Kullanıcının ne anladığını söylemez. İkisi birbirinin yerine geçmiyor: hızlı açılan bir form da yanlış etiketlenmiş olabilir, iyi yazılmış bir akış da üç saniyelik beklemede terk edilebilir. Performans ölçümünü otomatik koşturun, insan saatini anlamayı ölçmeye ayırın.
Sonuçları rapora gömmeyin
Otuz sayfalık test raporunu kimse okumuyor. Oturumun iki dakikalık kaydı, altına yazılmış tek cümlelik bulgu ve tahmini maliyet, ekip kanalında paylaşıldığında aynı işi görüyor. Kaydı izleyen geliştirici, yazılı bir cümleyle ikna edilemeyecek bir şeyi kendi gözüyle görüyor ve tartışma "bence kullanıcı anlar" noktasından çıkıyor.