Tree Testing: Menü Hiyerarşisini Etiketler Üzerinden Sınamak
Tree testing, bir menü yapısını görsel tasarımdan tamamen soyutlayıp geriye yalnızca kelimeleri bırakan bir test yöntemidir. Katılımcının önünde renk, ikon, arama kutusu ya da vitrin bloğu yoktur; sadece iç içe geçmiş başlıklardan oluşan bir liste ve bir görev vardır. Ölçtüğü şey de bu kadar dardır: insan, aradığı şeyin hangi başlığın altında durduğunu tahmin edebiliyor mu?
Yöntem neyi ölçer, neyi ölçmez
Bir kullanıcı sitenizde kaybolduğunda bunun iki ayrı sebebi olabilir. Ya menü isimleri onun kafasındaki kelimelerle örtüşmüyordur, ya da isimler doğrudur da sayfa tasarımı o menüyü görünmez kılmıştır. Bu iki sebep birbirine karışırsa yanlış şeyi düzeltirsiniz: etiket sorununu tasarımla, tasarım sorununu yeniden adlandırmayla çözmeye çalışırsınız.
Tree testing ikincisini denklemden çıkarır. Görsel hiçbir ipucu vermediği için elinizde kalan tek değişken bilgi mimarisidir. Buna karşılık test, sayfa içi bağlantıların, arama kutusunun ya da ana sayfadaki kısayolların işi ne kadar kurtardığını size söylemez. Gerçek sitede insanların önemli bir kısmı menüyü hiç kullanmadan hedefine gider. Tree test sonuçları bu yüzden sitenin genel başarısı değil, menünün tek başına ne kadar dayandığıdır.
Testin kurulumu
Süreç dört parçadan oluşur ve ilk ikisi işin çoğunu belirler.
- Ağacı çıkarın. Menünün tamamını, en alttaki yaprak sayfalara kadar, hiyerarşik bir tablo halinde yazın. Elle yazmak yerine site haritasından ya da menü tanımının kendisinden üretin (elle çıkarılan ağaçta neredeyse her zaman koddaki menüyle uyuşmayan bir dal çıkıyor, testi de o dal bozuyor).
- Görevleri yazın. Her görev, kullanıcının gerçekten yapmak isteyeceği bir işi anlatmalı. Görev metninde menüdeki kelimeleri kullanmayın; "Faturalandırma bölümünü bulun" diye sorarsanız cevabı da vermiş olursunuz. Bunun yerine niyeti tarif edin: "Geçen ay ne kadar ödediğinizi öğrenmek istiyorsunuz."
- Araca aktarın. Ağaç ve görevler bir teste dönüşür. Treejack bu iş için yaygın kullanılan araçtır, katılımcının izlediği yolu adım adım kaydeder.
- Yolları okuyun. Sonuç ekranında sizi ilgilendiren şey ortalama başarı yüzdesi değil, insanların hangi dala saptığıdır.
Görev sayısını 8 ila 10 arasında tutmak yaygın tavsiyedir. Sebebi katılımcının dikkati: aynı metin listesinde onuncu görevden sonra insanlar okumayı bırakıp tanıdık kelimeye tıklamaya başlar, o noktadan sonra topladığınız veri menüyü değil yorgunluğu ölçer.
Üç çıktı ve dolaylı başarının tuzağı
Analiz üç sayı üretir. Doğrudan başarı, katılımcının hiç geri dönmeden doğru yaprağa varmasıdır. Dolaylı başarı, bir veya birkaç yanlış daldan sonra doğru yere ulaşmasıdır. Başarısızlık, hiç ulaşamamasıdır.
Tuzak ortadaki sayıda. Dolaylı başarı da sonuçta başarıdır diye onu doğrudan başarıyla toplayıp tek bir oran çıkarmak, testin size söylediği en değerli şeyi siler. Çünkü dolaylı başarının izlediği yol, menünün tam olarak nerede yanlış söz verdiğini gösterir: kullanıcı önce hangi başlığı makul bulup açtı, açınca ne bulamadı, nereye geri döndü. Bir başlığın altında olmayan bir şeyi vaat etmesi, hiç anlaşılmayan bir başlıktan daha pahalıdır; ikincisinde kullanıcı geçip gider, birincisinde vakit kaybeder ve size güveni azalır.
Pratikte şuna bakın: aynı yanlış dal, farklı görevlerde tekrar tekrar açılıyorsa o dalın adı yanlış değil, kapsamı yanlıştır. Tek bir görevde bir kez sapma olmuşsa büyük ihtimalle görev metni bulanıktır, menü değil.
Sığ menü tavsiyesinin sınırı
Bilgi mimarisi tartışmalarında sık duyulan bir kural var: menüyü sığ tut, katman sayısını azalt, kullanıcı üç tıkta hedefe varsın. Bu tavsiyenin bir kısmı doğru, ama gerekçesi genelde yanlış kuruluyor.
64 yaprak sayfanız olduğunu düşünün. Bunları her düzeyde sekiz dala bölerek iki katmanda dizebilirsiniz (8 çarpı 8), ya da dörder dala bölerek üç katmanda (4 çarpı 4 çarpı 4). Rastgele tıklayan birinin doğru yaprağa varma olasılığı ikisinde de 1/64'tür. Katmanı azalttığınızda her katmandaki seçenek sayısı arttığı için kazandığınızı sandığınız şeyi geri verirsiniz.
Gerçek kullanıcı elbette rastgele tıklamaz, işin bütün mesele de burada. Fark yaratan şey katman sayısı değil, her adımda etiketlerin doğru dalı ne kadar ayırt edilebilir kıldığıdır. Birbirinden net ayrılan dört başlık, aralarındaki farkı kimsenin bilmediği yirmi başlıktan iyidir. Sığlaştırma ancak katmanları birleştirirken etiketleri de netleştiriyorsanız işe yarar; yalnızca derinliği kırpmak, kararı bir üst kata taşımaktan başka bir şey yapmaz.
Test bittikten sonra
Tree testing kendi başına bir yeniden adlandırma önerisi üretmez, sadece hangi başlıkların taşımadığını gösterir. Yeni isimleri bulmak için genellikle kart gruplama (card sorting) daha uygun düşer: orada kelimeleri siz değil kullanıcılar önerir. İkisini sırayla çalıştırmak mantıklı bir düzendir, kart gruplamayla aday bir ağaç kurulur, tree testing o ağacın gerçekten yürüyüp yürümediğini sınar.
Değişikliği yaptıktan sonra aynı görevlerle testi bir kez daha koşun. Menü düzenlemesi, doğrulaması ucuz olan nadir tasarım kararlarından biridir; bunu ölçmeden yapmak için pek bir sebep yok.