Kullanılabilirlik Bulgusundan Backlog Maddesine: Rapor Nasıl Yazılır
Kullanılabilirlik testinin çıktısı rapor değil, değişikliktir. Ekip raporu okuyup hangi ekranı açacağını bilmiyorsa o test yapılmamış sayılır. Farkı yaratan da bulgunun nasıl yazıldığı ve nereye kaydedildiğidir.
Belirsiz bulgu, bulgu sayılmaz
"Kayıt işlemi zordu" cümlesi rapora girdiği anda ölür. Geliştirici bunu okuduğunda elinde hiçbir şey yoktur: form mu uzun, hata mesajı mı geç çıkıyor, parola kuralları mı görünmüyor, belli değil. Bir bulgu satırı şu üç bilgiyi taşımadan ekibe ulaşmaz:
- Hangi ekranda, akışın hangi adımında olduğu
- Kaç katılımcıdan kaçının orada takıldığı
- Katılımcının takıldığında bunun yerine ne yaptığı: geri döndü, yanlış alanı doldurdu, vazgeçti
Üçü birden yazıldığında bulgu zaten kendi çözümünü işaret etmeye başlar.
Kullanıcıyı değil arayüzü işaret et, ama sayıyı silme
Yaygın tavsiye şudur: "3 kullanıcı linki bulamadı" yerine "Navigasyon menüsü linkin görünürlüğünü zorlaştırıyor" yaz. Suçu kullanıcıya yıkmamak doğru. Fakat bu düzeltme, cümledeki tek ölçülebilir veriyi, yani sayıyı da götürüyor ve bir önceki kuralla, spesifik olma kuralıyla açıkça çelişiyor. İkisi aynı cümlede durabilir: "8 katılımcının 3'ü üst menüdeki Destek bağlantısını göremeyip arama kutusuna yöneldi." Kimse suçlanmıyor, ölçü duruyor, altı ay sonra aynı görev tekrarlandığında karşılaştıracak bir sayı kalıyor.
Öncelik bir etiket değil, bir hesap
Düşük, orta, yüksek etiketleri tek başlarına sıralama üretmez. Bir sorunun sırasını iki şey belirler: kaç kişiyi durdurduğu ve durdurduğunda görevi bitirip bitiremedikleri. Üçüncü olarak düzeltme maliyeti gelir, ama o ekibin bileceği iştir, rapora yazılmaz.
Sekiz kişiden altısını durduran bir etiket sorunu ile tek kişiyi yavaşlatan bir akış sorunu aynı listede "yüksek" etiketini paylaşıyorsa liste sıralama işlevini kaybetmiş demektir. Pratik ölçüt basit: maddelerin üçte birinden fazlası yüksek öncelikliyse ölçek bozuktur, yeniden dağıt. Beş yüksek öncelikli madde, hepsi yüksek olan yirmi maddeden daha çok iş yaptırır.
Öneriyi yaz, tasarımı yapma
Raporda çözüm önerisi bulunmalı, yoksa bulgu havada kalır. Ama öneri, sorunun kendisinin yerine geçmemeli. "Butonu sağ üste al" yazdığında tasarımcının önüne tek bir seçenek koymuş olursun; "Katılımcılar ödeme adımında devam butonunu sayfa altında aradı" yazdığında ise çözüm alanını açık bırakırsın. Öneriyi ayrı bir satırda, açıkça öneri olarak işaretle.
Rapor kapanır, kayıt kalır
Her bulguya backlog'da bir madde aç. Tekrar üretme adımlarını ve ekran kaydının saniyesini o maddeye yapıştır, çünkü PDF'in içinde kalan bulgu sprint planına girmez, sprint planına girmeyen bulgu da düzelmez. Bulgu numarasını rapordan issue numarasına eşleyen tek satırlık bir tablo, altı ay sonra "bunu konuşmuş muyduk" tartışmasını bitirir.
Çalışan şeyleri de yaz. İkinci turda birisi o akışı "iyileştirmek" istediğinde, elinde onun zaten sorunsuz geçtiğine dair kayıt olur. Kurum içinde biriken böyle bir arşiv, yeni projede aynı menü hatasını ikinci kez yapmanın önündeki en ucuz engel.