Tree Testing Sonuçlarını Okumak: Başarı Oranı Yeterli Değil
Tree testing raporu açıldığında ilk bakılan sayı başarı oranıdır, çoğu zaman da bakılan tek sayı o kalır. Oysa aynı başarı oranı bambaşka iki bilgi mimarisinden çıkabilir: biri kullanıcıyı doğrudan hedefe götürür, diğeri üç yanlış dalda dolaştırıp sonunda şans eseri vardırır. Rapordan iş çıkarmanın yolu metrikleri tek tek değil, ikili okumaktan geçiyor.
Başarı oranı ve doğrudanlık, aynı tabloda
Doğrudanlık, kullanıcının geri dönmeden ve dal değiştirmeden hedefe ulaşma oranıdır. Başarı oranıyla birlikte dört farklı tablo kuruyor ve her biri farklı bir işi gerektiriyor:
| Başarı | Doğrudanlık | Ne anlama geliyor |
|---|---|---|
| Yüksek | Yüksek | Hiyerarşi ve etiket çalışıyor. Dokunma. |
| Yüksek | Düşük | İçerik doğru yerde ama yolu birden fazla dal üstünden geçiyor. Genelde örtüşen etiket sorunu. |
| Düşük | Yüksek | Kullanıcılar kararlı biçimde yanlış dala gidiyor. İçerik yanlış yerde, etiket değişikliği kurtarmaz. |
| Düşük | Düşük | Görev kullanıcı diline çevrilememiş ya da o seviyede hiyerarşi kafa karıştırıyor. Baştan kurgula. |
Bir e-ticaret projesinde başarı oranı %80 üstündeydi ama doğrudanlık onun yarısı kadar çıkmıştı; sebep "Hesabım" ile "Siparişlerim" dallarının birbirinin yerine geçebilir görünmesiydi, iki dalı birleştirince iki metrik de aynı seviyeye oturdu. İkinci satır en çok yanlış okunan satırdır: başarı oranı iyi göründüğü için sorun rapordan hiç çıkmaz, oysa kullanıcı aynı işi iki katı adımla yapıyordur.
İlk tıklama, zihindeki haritayı gösterir
İlk tıklama, kullanıcının görevi hangi başlığın altında aradığını söyler. Buradaki dağılımın şekli, sayısından daha fazla bilgi taşır. Tıklamalar üç dört dala saçılmışsa etiketler kavramsal olarak örtüşüyor, kullanıcı hangisinin ne kapsadığını ayırt edemiyor. Tek bir yanlış dalda yoğunlaşmışsa durum tersidir: kullanıcılar kendi aralarında tutarlıdır, hiyerarşi onlara uymuyordur. İkinci durumda içeriği kullanıcının gittiği yere taşımak, mevcut yerdeki etiketi cilalamaktan daha hızlı sonuç verir.
Doğru tamamlanan görevlerde son seçilen dalı da ayrıca okumak gerekir. İlk tıklama ile nihai hedef farklı dallarda toplanıyorsa, menüde kullanıcıyı önce çeken ama işini görmeyen bir başlık var demektir.
İki ağacı karşılaştıracaksan hesabı önce yap
Tree testing'in iki alternatif menüyü kıyaslamak için kullanıldığı yerde çoğu ekip 30 ile 50 kişilik örneklemle çalışıyor ve çıkan farkı bulgu sayıyor. İki oranı karşılaştırmanın gücü, bu ölçekte buna yetmez. Kabaca gereken katılımcı sayısı ağaç başına 16·p(1−p)/Δ² ile büyür. Başarı oranını %62'den %72'ye çıkardığını göstermek istiyorsan, 16 × 0,67 × 0,33 / 0,01 hesabı ağaç başına yaklaşık 350 kişi verir. Elinde 40 kişi varsa güvenilir biçimde ayırt edebileceğin en küçük fark 30 puan civarındadır; bu büyüklükte bir fark zaten teste gerek bırakmaz.
Pratik sonuç şu: küçük örneklem tek bir ağacın nerede tıkandığını teşhis etmek için yeterlidir, iki ağacı sıralamak için değil. Aynı katılımcıya iki ağacı birlikte verip örneklemi büyütmek de işe yaramaz, ikinci ağaçta görevi zaten öğrenmiş olur. Kıyaslamayı gerçekten yapacaksan katılımcıları iki gruba bölüp her grubu tek ağaca sokman, görev sırasını da gruplar arasında döndürmen gerekir.
Rapordan değişikliğe
Düşük başarı oranı çıkan her göreve ayrı ayrı bakmak yerine, aynı dalda toplanan görevleri birlikte ele al. Tek bir yanlış kurulmuş üst kategori, altındaki beş görevin metriğini birden bozar; onu düzeltmek beş ayrı etiket denemesinden kısa sürer.
İçeriği birden fazla kategoriye koyarak sorunu kapatmak cazip görünür ve kısa vadede başarı oranını da yükseltir. Fakat her çoklu yerleşim, menüyü üreten tarafta bir karar daha demektir: yeni içerik hangi dallarda görünecek, hangisi kanonik sayılacak, arama ve breadcrumb hangisini gösterecek. İki üç yerde durdurursan yönetilir, kural haline getirirsen bir yıl sonra kimse menünün neden o şekilde olduğunu açıklayamaz. Bu yüzden önce tek doğru yeri bulmayı dene, çoklu yerleşimi gerçekten iki eşit meşru yolun olduğu yere sakla.
Bir de şu var: görev ifadesi menüdeki etiketin kelimesini içeriyorsa test ettiğin şey bilgi mimarisi değil, kelime eşleştirmedir. Sonuçları yorumlamaya başlamadan önce görev metinlerini bu açıdan okumak, metriklerin yarısını baştan kurtarır.