UX Araştırma Yöntemleri: Hangisi Hangi Soruya Cevap Verir
UX araştırma yöntemlerinin listesi uzun, ama tek bir projede hepsine yer yok. Asıl iş, elindeki sorunun hangi yöntemle cevaplandığını seçmek: insanların o işi bugün nasıl yaptığını mı merak ediyorsun, arayüzün belirli bir ekranda tökezleyip tökezlemediğini mi, yoksa kaç kişinin etkilendiğini mi? Yanlış eşleşme, kusursuz yürütülmüş bir çalışmayı bile boşa çıkarır.
Araştırma ne zaman yapılır
Kod yazılmadan önce. "Her aşamada yapılabilir" doğru bir cümle ama işe yaramaz bir tavsiye, çünkü aynı bulgunun maliyeti aşamaya göre kat kat değişir. Tasarım dosyasında yanlış kurgulanmış bir akışı değiştirmek birkaç saat, aynı akış üretime çıktıktan sonra veri modeline yerleşmişse haftalar sürer. Geç kalınmış araştırmanın tipik sonucu, bulguların "sonraki sürüme" yazılıp orada unutulmasıdır.
Bütçe dar olduğunda tek bir çalışma seçeceksen, bunu ilk ekran taslakları ortaya çıktığı anda yap.
Soruya göre yöntem
| Cevabını aradığın soru | Yöntem |
|---|---|
| Bu işi bugün nasıl yapıyorlar? | Saha gözlemi, kullanıcı mülakatı, günlük çalışması |
| Arayüz şu görevde tökezliyor mu? | Sesli düşünme testi |
| İsimlendirme ve gruplama tutuyor mu? | Kart sıralama, ardından ağaç testi |
| Kaç kişi etkileniyor? | Analitik, anket |
| Ne arıyorlar, nasıl adlandırıyorlar? | Site içi arama kayıtları, destek talepleri |
Bu tablonun en ucuz satırı sonuncusu. Arama kayıtları ve destek talepleri zaten sistemde duruyor, katılımcı bulmak, takvim ayarlamak, kayıt almak gerekmiyor; bir sorgu yazıp bakmak yetiyor. Bir e-ticaret projesinde arama kayıtlarını açtığımda sorguların çoğunun kategori adı değil marka ve model numarası olduğunu gördüm, menü hiyerarşisi tartışması o gün kapandı.
Kart sıralamayı yalnız bırakma. Kart sıralama insanların nasıl grupladığını söyler, o gruplamayla gerçekten hedefe ulaşıp ulaşamadıklarını söylemez. İkincisi için ağaç testi gerekir ve çoğu ekip bu ikinci adımı atlayıp elindeki kümeleri bilgi mimarisi sanır.
"Beş kullanıcı yeter" nereye kadar doğru
Nielsen'in bilinen hesabı şuna dayanır: tek bir kullanıcının ortalama bulduğu sorun oranı L ise, n kişiyle bulunan toplam oran 1-(1-L)^n olur. L 0,31 alındığında beş kişi sorunların yaklaşık %84'ünü ortaya çıkarır, onuncu kişi bu orana ancak birkaç puan ekler. Rakam bu yüzden beştir.
Formülün sessiz varsayımı şu: katılımcıların hepsi aynı kitleden ve aynı görevleri yapıyor. Ürünün hem son kullanıcısı hem de yönetici paneli varsa beş kişilik tek bir oturum iki kitleyi birden temsil etmez, iki ayrı beşli gerekir. İkinci sınır daha sık atlanıyor: bu hesap sorun bulmakla ilgilidir, ölçmekle değil. Görev başarı oranını ya da süresini sayıyla raporlayacaksan beş kişilik örneklem sana yalnızca çok geniş bir güven aralığı verir, o tabloyu sunuma koyma.
Karşılaştırmalı ölçüm nerede bozulur
Sürümler arası karşılaştırma yapacaksan görev metni, başlangıç noktası ve başarı tanımı harfi harfine sabit kalmalı. Görev cümlesini "daha anlaşılır olsun" diye ikinci turda yeniden yazan ekip, karşılaştırma değil birbirinden bağımsız iki çalışma üretmiş olur ve bunu fark etmeden yüzdeleri yan yana koyar.
Başarı tanımını ölçüme başlamadan önce yaz. "Kullanıcı ödeme ekranına ulaştı" ile "kullanıcı yardım almadan ödeme ekranına ulaştı" farklı iki metriktir ve çalışma bittikten sonra hangisini kullanacağına karar vermek, veriyi istediğin sonuca göre seçmek anlamına gelir.
Toplanan veriyle ne yapılır
Katılımcıdan işin gerektirdiğinden fazla kişisel bilgi isteme; ad soyad ve iletişim bilgisi çoğu çalışmada hiç gerekmez, katılımcı numarası yeter. Kayıtları süresiz saklamak da kimseye fayda getirmiyor, analiz bitince ham video ve ses dosyalarının ömrünü baştan belirle.
Bulguları ise sakla. Altı ay sonra aynı ekranı yeniden tartışırken "bunu daha önce test etmiştik" diyebilmek, o testi ikinci kez yapmaktan çok daha ucuz.