Destek Sitelerinde İteratif Test ve Doğru Başarı Ölçütü

Destek sitelerinin çoğu bilgi eksikliğinden değil, bilgi fazlasından çöker. Yanıt sitede vardır, kullanıcı bulamaz. Bu bir içerik üretme problemi değil, bilgi mimarisi ve arama problemidir; iteratif test de tam olarak bunu çözmek için vardır. Asıl mesele testi kurmak değil, sonucunu neye bakarak okuyacağını baştan kararlaştırmaktır.

Sorun bulunabilirlikte, kapsamda değil

Dokümantasyon büyüdükçe iki şey aynı anda olur: aranan sayfa yazılır ve aranabilirliğini kaybeder. Aynı konu üç farklı başlık altında, biri güncel ikisi eski. Kullanıcı üçünü de açar, hangisinin geçerli olduğunu anlayamaz, foruma soru yazar. Destek yükünün önemli bir kısmı cevaplanmamış sorulardan değil, çelişen cevaplardan doğar.

Bu yüzden destek sitesi iyileştirmesine içerik yazarak başlamak yanlış sıralamadır. Önce mevcut içeriğin hangi kısmının ölü olduğu, hangi başlıkların birbirini tekrarladığı ve kullanıcının aramada hangi kelimeleri kullandığı tespit edilir. Silmek, yazmaktan daha çok iyileştirir.

Kaç kullanıcı, kaç tur

İteratif test, bir tasarımın kısa aralıklarla gerçek kullanıcıya gösterilmesi ve her turda düzeltilmesidir. Buradaki kritik karar, örneklem büyüklüğü değil turların sayısıdır.

Nielsen Norman Group'un beş kullanıcı kuralı basit bir olasılık modeline dayanır: tek bir kullanıcının rastgele bir kullanılabilirlik sorununu yakalama olasılığı L ise, n kullanıcının bulacağı sorun oranı 1-(1-L)^n olur. L yaklaşık 0,31 alındığında beş kullanıcı sorunların yaklaşık %85'ini ortaya çıkarır. On beş kullanıcı %99'a yaklaşır, ama hepsi aynı sürümü test etmiş olur.

Aynı bütçeyi üçe bölüp beşer kullanıcıyla üç tur yaparsan, her turda düzeltilmiş yeni bir sürüm test edilir. İlk turda bulunan hatalar ikinci turda ortadan kalktığı için ikinci tur, birinci turun gölgelediği daha derin sorunları görünür kılar. Tek turluk on beş kişilik test bunu asla veremez: on beş kişi de aynı yüzeysel engele takılır, arkasındaki gerçek sorun hiç ortaya çıkmaz. Destek sitesi gibi sürekli değişen bir üründe tur sayısı her zaman katılımcı sayısından değerlidir.

Ucuz veriyi önce tüket

Test turuna girmeden önce elindeki iki veri kaynağını boşalt: site içi arama logları ve sonuç dönmeyen sorgular. Sonuç bulunamayan aramalar, kullanıcının kelimesiyle senin başlığın arasındaki farkı doğrudan gösteren en dürüst listedir. Bir sorgu haftada yüzlerce kez sonuçsuz dönüyorsa cevap ya yok ya da yanlış adlandırılmış.

Bunun için analitik paketi kurmaya gerek yok. Arama kutusundan geçen sorguyu bir tabloya yazan on satırlık bir kayıt ve haftada bir çalışan tek bir GROUP BY sorgusu, çoğu hazır aracın gösterdiğinden fazlasını verir; üstelik veri sende kalır, örnekleme kaybı olmaz.

Kağıt prototip aynı mantıkla çalışır. Yeni gezinme yapısını kodlamadan önce başlıkları kağıda yazıp beş kişiye "faturanı nereden bulursun" diye sordur. Yanlış yapıyı beş dakikada değil, canlıya aldıktan altı hafta sonra öğrenmek pahalıdır.

Destek talebindeki düşüş tek başına başarı değildir

Destek sitesi projelerinde en sık kullanılan ölçüt, açılan talep sayısındaki azalmadır. Bu ölçüt tek başına kullanıldığında yanıltıcıdır, çünkü talep sayısı iki bambaşka nedenle düşer: kullanıcı cevabı bulduğu için ya da kullanıcı aramaktan vazgeçtiği için. İkinci durum ölçümde birincisiyle aynı görünür, oysa ürün açısından bunlardan biri başarı, diğeri kayıptır.

Ayrımı yapmanın yolu, düşüşü tek başına okumamaktan geçer. En az üç ölçüm birlikte izlenmeli:

• Arama yapıp hiçbir sonuca tıklamadan çıkanların oranı, yani başarısız arama
• Yardım sayfasını gördükten sonra yine de talep açanların oranı, yani yetersiz cevap
• Aynı kullanıcının aynı konuda ikinci kez dönme sıklığı

Talep sayısı düşerken başarısız arama oranı da düşüyorsa iyileşme gerçektir. Talep düşüp başarısız arama artıyorsa yaptığın şey destek yükünü azaltmak değil, kullanıcıyı yormaktır. Bu ikisini ayırmadan açıklanan yüzdelik iyileşme rakamlarına itibar etme.

Sürekliliği içerik sahipleri taşır

Destek içeriği yayınlandığı gün doğru, altı ay sonra genellikle yanlıştır. Ürün değişir, ekran görüntüsü eskir, menü adı başkalaşır. Bu yüzden iteratif testin çıktısı sadece yeni bir tasarım değil, içeriğin kim tarafından ve hangi sıklıkta gözden geçirileceğine dair bir sorumluluk dağılımı olmalıdır.

Pratikte işleyen yöntem şu: her destek sayfasının bir sahibi ve bir son doğrulama tarihi olur, tarih geçtiğinde sayfa arama sonuçlarında kendiliğinden geri düşer. Yaptırımı olmayan güncelleme takvimi ilk yoğun haftada terk edilir. Eski adresleri de aynı disiplinle yönet: yeniden yapılandırdığın her başlık için kalıcı yönlendirme bırak, çünkü destek sayfalarının bağlantıları e-postalarda ve forum cevaplarında yıllarca dolaşır.

Sonuçta destek sitesi tasarımı bir kerelik proje değil, ölçüm alışkanlığıdır. Turları kısa tut, katılımcı sayısını abartma, düşen rakamı alkışlamadan önce neden düştüğünü sor.