Görev Sürelerindeki Değişkenlik ve Hangi Sayıya Bakmak Gerekir

Aynı görevi yapan iki kullanıcı arasındaki süre farkı, web arayüzlerinde diğer yazılım türlerinin çoğundan daha geniştir. Bu dağılımı sıfırlayamazsınız, ama ölçtüğünüz sayıyı değiştirerek yönetebilirsiniz. Ortalama görev süresi bu iş için yanlış sayıdır ve çoğu test raporunun tek verdiği sayı odur.

Önce ölçtüğünüz sayıyı değiştirin

Bir görevde ortalama süre iyileşmiş görünüyorsa bu genellikle hızlı dilimin biraz daha hızlanmasından kaynaklanır. Zorlanan kullanıcı zorlanmaya devam eder, ortalamada kaybolur.

Sunucu tarafında kimse ortalama yanıt süresine bakmıyor, p95'e bakıyor; çünkü sistemin gerçek sorunu kuyruğun ucunda yaşanıyor. Kullanılabilirlik testinde de aynısı geçerli. Yavaş dilimin süresini raporlayın, iyileştirme hedefini oraya koyun (ortalamayı hiç yazmamak bile bir kayıp sayılmaz).

Buna bağlı bir uyarı: küçük katılımcı sayısıyla süre dağılımının ucunu güvenilir biçimde kestiremezsiniz. Beş kişilik test sorunları bulmak için yeterlidir, süre yüzdeliği hesaplamak için değil. Beş kişiyle çalışıyorsanız saniyeleri karar dayanağı yapmayın, nerede takıldıklarını not edin.

Farkın nereden geldiği

Testlerde tekrar tekrar gözlenen tablo şu: bir şirketin iletişim adresini bulmak gibi basit bir görevde en hızlı kullanıcı yaklaşık yarım dakikada bitirirken, en yavaş kullanıcı yedi dakikaya kadar çıkabiliyor. Metin düzenleme gibi görevlerde bu makas belirgin biçimde daha dar.

Sebep genelde kullanıcının kendisi değil, arayüzün kullanıcıya bıraktığı iş:

• Gezinme yapısı kullanıcının zihnindeki modelle uyuşmuyor, doğru bölümü bulmak deneme yanılmaya dönüşüyor.
• Bir adımda öğrenilen bilgi sonraki adımda yeniden gerekiyor, kullanıcı akılda tutmak zorunda kalıyor.
• Seçenek sayısı karar noktalarını çoğaltıyor, her karar da bir duraklama üretiyor.

Web deneyimli kullanıcı bu boşlukları hızla dolduruyor, deneyimsiz kullanıcı her birinde duruyor. Değişkenliğin kaynağı burası.

Doğrudan işe yarayan müdahaleler

Yavaş dilimi hızlandıran değişiklikler, hızlı dilimi hızlandıranlardan farklı. Klavye kısayolu, gelişmiş filtre, kişiselleştirme: bunlar zaten hızlı olanı hızlandırır. Yavaş dilim için sırasıyla şunlar işe yarar:

1. Görevi tamamlamak için gereken adım sayısını düşürün. Bir adım silmek, kalan adımları güzelleştirmekten her zaman daha fazla kazandırır.
2. Kullanıcının nerede olduğunu her ekranda görünür kılın. Breadcrumb ve okunabilir url yapısı, geri dönüp yeniden başlama davranışını azaltır.
3. Hatayı geri alınabilir yapın. Yanlış yola sapmanın maliyeti düşükse, kullanıcı denemekten çekinmez ve duraklama süresi kısalır.
4. Sayfa yükleme süresini görev süresinden ayrı ölçün. İkisi karışırsa, tasarım sorunu sanılan şey aslında altyapı sorunu çıkabilir.
5. Mobil düzeni ayrı test edin. Dar ekranda gizlenen menü, masaüstünde olmayan bir arama adımı ekler.

Bu farkın maliyeti

Yavaş dilimdeki kullanıcı sessizce ayrılır, form yarım kalır, arama sonuç vermeden kapanır. Bu kullanıcılar analitikte genelde düşük ilgi gibi görünür, oysa arayüzün onlara bıraktığı iş fazladır.

Değişkenliği tamamen kapatmak diye bir hedef koymayın. Ölçüyü doğru yere taşıyın, sonra en yavaş dilimin süresini adım adım aşağı çekin. Bir görevde bu sayı düşüyorsa arayüz gerçekten iyileşmiştir.