Wizard of Oz Yöntemi: Sistemi Yazmadan Arayüzü Test Etmek
Chatbot, sesli asistan ya da öneri motoru gibi arayüzlerde asıl merak edilen şey teknolojinin çalışıp çalışmadığı değil, kullanıcının o arayüzle nasıl konuştuğudur. Bunu öğrenmek için sistemi yazmanız gerekmez. Wizard of Oz testinde yanıtları arka plandaki bir kişi üretir, kullanıcı otomatik bir sistemle etkileşimde olduğunu sanır ve doğal davranır. Kurulumu ucuz, sonuçları değerli, ama ölçtüğü alan sanıldığından dar.
Nerede kurmaya değer
Yöntem, girdinin serbest olduğu ve doğru yanıtın önceden bilinemediği arayüzlerde işe yarar. Konuşmaya dayalı botlar, sesli komut prototipleri, kişiselleştirilmiş öneri akışları, gerçek zamanlı veri gösteren ekranlar. Ortak nokta şu: sistemi kodlamanın maliyeti yüksek, kullanıcının nasıl ifade edeceğini tahmin etmenin maliyeti ise sıfıra yakın. Formu iki sütuna mı bölsem sorusu için Wizard of Oz kurmayın, orada tıklanabilir prototip yeter.
Kurulum
- Kullanıcının göreceği arayüzü hazırlayın. Figma'da tıklanabilir bir akış çoğu zaman yetiyor, sohbet arayüzü içinse basit bir mesaj penceresi daha gerçekçi duruyor.
- Büyücünün ekranını ayırın. Kullanıcı ne yazdı, hangi yanıt gidecek, bunu ikinci bir cihazdan yönetin (aynı makinede iki pencereyle idare etmeye çalışan her kurulum bir yerde tökezliyor).
- Yanıt kütüphanesini önceden yazın, gecikmeyi de yazın: her yanıtın kaç saniye sonra görüneceğine karar verin.
- Büyücüyü moderatörden ayrı tutun. Aynı kişi hem katılımcıyla konuşup hem yanıt üretirse ikisi de kötü yapılır.
- Bir pilot oturum koşun. İlk pilotta neredeyse her zaman senaryo dışına çıkan bir girdi geliyor, kütüphaneyi ona göre genişletin.
Kapalı model kaçıncı turda çöker
Yanıtları önceden yazmak analizi kolaylaştırır: her katılımcı aynı uyaranı görür, oturumlar karşılaştırılabilir. Sorun ölçekte. Kullanıcının ilk mesajı için on farklı ifade biçimi öngördüyseniz, iki turluk bir diyalogda kapsamanız gereken yol sayısı yüze çıkar, üç turda bine. Kapalı model bu yüzden tek turluk komutlarda mükemmel, çok turlu sohbette dördüncü replikte tükeniyor.
Açık modelde büyücü anlık yanıt üretir, konuşma doğal ilerler. Bunun bedeli genelde "analiz zorlaşır" diye geçiştiriliyor, oysa daha sert bir şey oluyor: aynı girdiye iki farklı oturumda iki farklı yanıt verildiğinde katılımcılar arası karşılaştırma geçerliliğini kaybeder. Yani "açık model daha gerçekçi" tavsiyesiyle "oturumları karşılaştırıp örüntü çıkaralım" hedefi aynı testte birlikte yürümez. Seçimi buradan yapın: keşif yapıyorsanız açık, karşılaştırma yapıyorsanız kapalı. Hibrit ise ikisinin ortası değil, kritik anlarda sabit yanıt kullanıp gerisini serbest bırakma disiplinidir; sabitlenen anları önceden listelemezseniz hibrit dediğiniz şey açık modele dönüşür.
Büyücünün gecikmesi ölçümü bozar
Arka plandaki kişi mesajı okur, kararını verir, yazar. Bu üç ile on saniye arası bir gecikme demektir. Gerçek sistem ise ya iki yüz milisaniyede yanıt verecek ya da hiç veremeyecek. Aradaki farkı önemsemezseniz test size kullanıcının sabrı, boşluk anındaki tereddüdü ve "acaba gönderemedim mi" davranışı hakkında tamamen yanlış veri üretir. Çözüm basit: yanıtları sabit bir gecikmeyle serbest bırakın, hedeflediğiniz gerçek yanıt süresini baştan seçin ve büyücü hazır olsa bile o süre dolmadan göndermeyin. Kullanıcı tarafında bir "yazıyor" göstergesi varsa onu da aynı senaryonun parçası sayın.
Zappos örneği bu yönteme sayılmaz
Wizard of Oz anlatılırken hemen her metinde Zappos çıkar: kurucu siparişleri elle karşılamış, sistem otomatikmiş gibi görünmüş. Doğru ama farklı bir soruyu yanıtlıyor. Orada test edilen şey arayüz değil, talebin var olup olmadığıydı; çıkan bulgu "insanlar ayakkabıyı internetten alır" oldu, "kullanıcı şu ekranda takılıyor" değil. İş modeli doğrulaması ile arayüz araştırmasını aynı torbaya koymak, ekipten yanlış çıktı beklemenize yol açar. UX tarafında beklentiniz somut olmalı: hangi ifadeler kullanıldı, sistem yanlış anladığında kullanıcı ne yaptı, hangi noktada vazgeçti.
Aldatma ve bilgilendirme
Yöntem tanımı gereği katılımcıdan bir şey saklar. Bunu meşru kılan tek şey oturum sonundaki açıklamadır. Testin bitiminde arka planda bir kişinin yanıt ürettiğini söyleyin, kayıtların ne için kullanılacağını anlatın, katılımcı isterse verisinin silinmesini kabul edin. Öncesinde "geliştirme aşamasındaki bir sistemi test ediyoruz" demek yeterli, detay vermek zorunda değilsiniz. Bunu iş yükü olarak görmeyin: sonraki turda aynı havuzdan katılımcı çağıracaksınız ve bir kez kandırılmış hisseden kişi geri gelmiyor.