B2B Sitelerde Bilgi Mimarisini Niceliksel Olarak Ölçmek
B2B sitelerde bulunabilirlik sorunu önce satış ekibinde görünür: aynı soru günde on kez gelir, çünkü ürün sitede üç tık ötededir ama yanlış kategorinin altındadır. Bilgi mimarisini değiştirmek bu yükü gerçekten azaltır. Zor olan kısım değişikliğin işe yaradığını kanıtlamaktır, ve çoğu ekip orada elindeki sayıya olduğundan fazla güvenir.
Önce ucuz veriyi topla
Kullanıcı testi kurmadan önce zaten sahip olduğun kayıtlara bak. Destek talepleri ve satış temsilcilerinin not defteri, hangi kategori adının yanlış anlaşıldığını bir tree test'ten daha hızlı söyler. Site içi arama raporu da öyle: kullanıcılar neyi menüde bulamayıp arama kutusuna yazıyorsa, menünün açığı odur. Analytics tarafında bu raporu açmak beş dakikalık iş (çoğu B2B sitede hiç açılmamış olmasını hâlâ tuhaf buluyorum).
Sıfır sonuç dönen aramalar ve iç bağlantılardan gelen 404'ler ikinci listeyi verir. Bu iki liste elindeyken test görevlerini rastgele değil, gerçekten sorun çıkaran yollar üzerinden yazarsın.
Tree test neyi ölçer, neyi ölçmez
Tree test yalnızca etiketleri ve hiyerarşiyi sınar. Görsel tasarım, arama kutusu, ürün fotoğrafı, filtre paneli yoktur. Bu bir eksiklik değil, kasıtlı bir yalıtım: skor düştüğünde suçun kategori adında olduğunu bilirsin. Buna karşılık gerçek sitede kullanıcının çoğu zaman arama kutusuna kaçtığını da unutmamak gerekir, yani tree test skoru üretimdeki görev başarısının üst sınırı değil, sadece navigasyon kolunun kalitesidir.
Görev metnini yazarken hedef kategorinin adını cümlede geçirirsen testi çöpe atarsın. "Endüstriyel Hortumlar bölümünden 2 inç hortum bul" diye sorarsan katılımcı etiketi eşleştirir, bilgi mimarisini değil kelime eşleşmesini ölçmüş olursun. Görev kullanıcının kafasındaki dille yazılır: "Fabrikada basınçlı hava hattı için hortum lazım, hangisini alacağını bulacaksın."
Card sorting bunun öncesine düşer. Açık kart tasnifi kategori adlarını kullanıcıya yazdırır, kapalı tasnif ise mevcut kategorilerin doğru anlaşılıp anlaşılmadığını sınar. Sıralama açıktır: önce card sorting ile yapıyı kur, sonra tree test ile sına.
4/10'dan 7,4/10'a çıkan skor ne kadar gerçek
Bu tip vaka anlatımlarında bulunabilirlik skorunun 4/10'dan 7,4/10'a çıktığı ve "%85 iyileşme" sağlandığı söylenir. Göreli hesap doğrudur, 7,4 bölü 4 gerçekten 1,85 eder. Sorun hesapta değil, sayının altındaki örneklemde.
10 katılımcıyla ölçülen %40'lık bir başarı oranının %95 güven aralığı, Wilson yöntemiyle kabaca %17 ile %69 arasındadır. Yani gerçek oranın %20 mi yoksa %65 mi olduğunu bilmiyorsun. Aynı %40 otuz katılımcıyla ölçülürse aralık %25-%58'e, elli katılımcıyla %28-%54'e iner. Tek başına 4/10 ile 7,4/10 arasındaki fark, katılımcı sayısı düşükken iki aralığın çakışmadığını göstermeye yetmez.
İkinci tuzak taşıma etkisidir. Ön testi yapan katılımcıya birkaç gün sonra son testi yaptırırsan, iyileşmenin ne kadarı yeni yapıdan ne kadarı görevleri hatırlamasından geldiğini ayıramazsın. Ön ve son test farklı katılımcı gruplarıyla, aynı görev setiyle yapılır. Görev setini de değiştirirsen karşılaştıracak bir şey kalmaz.
Pratik kural: 30 katılımcının altındaki tree test sonucunu karar gerekçesi değil, yön göstergesi say. Yön göstergesi olarak fena değildir, katılımcıların hangi yanlış dala saptığı 8 kişide bile açıkça görünür. Ama "%85 iyileştik" cümlesini yönetim sunumuna koymak için o sayının arkasında yeterli kişi olmalı.
Sadeleştirmenin kod tarafındaki faturası
Kategori sayısını azaltmak arayüz tarafında ucuz görünür, uygulama tarafında değildir. Taksonomi değişince kategori URL'leri değişir, eski adreslerin tamamı yönlendirilmek zorundadır, ve birkaç yeniden yapılanma üst üste binince zincirleme yönlendirmeler oluşur. Zinciri her seferinde son hedefe düzleştir, aksi halde hem tarayıcı hem tarayıcı botu gereksiz turlar atar.
Yönlendirme dışında iç bağlantılar, site haritası, kategori bazlı filtre parametreleri ve varsa besleme dosyaları da güncellenir. Bunun ağrısını azaltmanın yolu baştan bellidir: kategori kimliğini URL metninden bağımsız tut, böylece etiketi değiştirmek veri tarafında bir taşıma işine dönüşmez.
Testten sonra neyi izlemeye devam edersin
Tree test laboratuvar ölçümüdür, üretimde karşılığı olan göstergeler ayrıdır. Kategori sayfasından ürün sayfasına geçiş oranı, site içi arama kullanan oturum yüzdesi, aynı oturumda üçten fazla kategori gezen kullanıcı oranı ve destek tarafına gelen "nerede bulurum" talebi sayısı, dördü birlikte bilgi mimarisinin gerçekten düzelip düzelmediğini gösterir. Arama kullanım oranının düşmesi burada iyi haberdir: menü işini yapıyor demektir.
Ölçüm penceresini de sabitle. Yeni yapıyı yayına aldıktan sonra en az bir tam iş döngüsü boyunca başka bir değişiklik yapmadan veri topla, B2B'de bu çoğu zaman dört haftadır çünkü satın alma kararları haftalık dalgalanır. Aynı hafta içinde menüyü de ürün sayfasını da değiştirirsen, elinde iyileşmenin nereden geldiğini söyleyemeyeceğin bir grafik kalır.