Sesli Arayüzlerde Kullanılabilirlik Testi Nasıl Değişir

Sesli asistanla konuşan kullanıcı ne yaptığını göremiyor, biz de ne yaşadığını izleyemiyoruz. Ekran testlerinden alışık olduğumuz tıklama izi, göz takibi, araya girip soru sorma; burada ya işe yaramıyor ya da testin kendisini bozuyor. Elde kalan yöntemler dar, ama hangisinin nerede çalıştığı belli.

Sesle etkileşim neyi ölçülemez kılıyor

Yazılı arayüzde kullanıcı komutu kısaltır, sesli arayüzde konuşur. Cümlenin ortasında durur, geri döner, "ııı" der, soruyu iki kez farklı biçimde sorar. Ekranda kalan bir geçmiş yok; kullanıcı bir önceki adımda ne duyduğunu hatırlamak zorunda, üstelik hatırlamaya çalışırken sıradaki yanıtı kaçırıyor.

Peki bu koşulda "kullanıcı nerede takıldı" sorusunu neye bakarak cevaplayacağız? Ekran kaydı yok, tıklama akışı yok. Geriye sesin kendisi ve kullanıcının sonradan anlattıkları kalıyor.

Think-aloud'un yerine ne geçiyor

Düşünerek yüksek sesle konuşma yöntemi sesli arayüzde kendi kendini yiyor: kullanıcının moderatöre söylediği her cümle mikrofona da giriyor, sistem onu komut sanıyor, oturum bambaşka bir yere sapıyor. Araya girip soru sormak da aynı sebeple riskli.

Pratikte geriye retrospektif sorgulama kalıyor: görev bitiyor, sonra konuşuyorsunuz. Zayıf tarafı açık, kullanıcı yakın geçmişi yanlış hatırlayabilir. Ama sesli arayüzde bu yöntemi yanlış hatırlama riskine rağmen tercih ederim, çünkü alternatifi ölçtüğü şeyi bozan bir yöntem. Hatalı hatıra düzeltilebilir, bozulmuş oturum düzeltilemez.

Sorgulamayı işe yarar hale getiren şey soruların soyutluk seviyesi. "Deneyim nasıldı" diye sorarsanız kibarlık cevabı alırsınız. "Aldığınız bilgiyle şu işi yapabilir miydiniz", "hangi cümleyi tekrar dinlemek istediniz" gibi sorular kullanıcıyı belirli bir ana geri götürür.

Transkript ne kaydeder, ne kaydetmez

Sesli oturumun log'u genelde konuşma tanıma çıktısıdır. Yani kullanıcının söylediği değil, sistemin duyduğunu sandığı şey. Ask GeorgiaGov testlerinde çıkan klasik örnek bunun tam karşılığı: kullanıcı "license" diyor, sistem "Lawson's" olarak yazıyor. Ertesi gün log'u okuyan kişi kullanıcının Lawson's diye bir şey aradığını görür ve hatayı kullanıcının garip sorgusuna yazar.

Bu hata sınıfı transkriptte görünmez, çünkü transkript zaten hatanın kendisidir. Ham ses olmadan ayırt edemezsiniz: kullanıcı mı anlaşılmaz konuştu, tanıma modeli mi tökezledi, yoksa kelime dağarcığında o terim hiç mi yok. Üçünün çözümü birbirinden tamamen farklı. Ben oturumları genelde ham sesle birlikte saklarım; transkript arama için iyidir, hakemlik ham seste yapılır.

Aynı sebeple sesli ürünlerde "tanıma doğruluğu %95" gibi bir metrik tek başına bir şey söylemez. O yüzdeyi hesaplayan referans metni yine tanıma çıktısından üretilmişse ölçüm kendi kendini onaylıyor demektir.

Web metni sese doğrudan taşınmaz

Sitedeki metni olduğu gibi asistana okutmak en yaygın hata. Ekranda anlamlı olan yönlendirmeler seste boşluğa düşer.

Web içeriği	Sesli karşılığı
"Daha fazla bilgi için tıklayın."	"Bu konuda ayrıntı için ilgili müdürlüğü arayabilirsiniz, numarayı söyleyeyim mi?"
"Ödeme detayları için buradan devam edin."	"Ödemeyi kredi kartıyla, havaleyle veya vezneden yapabilirsiniz."

Bunun kalıcı çözümü metni iki kez yazmak değil, içeriği kanaldan bağımsız parçalar halinde tutmak. A List Apart'taki şu yazıda anlatıldığı gibi, sese özel olarak ayrı tutulan içerik kısa sürede ana içerikten kopuyor ve kullanıcıya eski bilgiyi veriyor. Yapılandırılmış içerik modeli burada tasarım tercihi değil, bakım maliyeti meselesi.

Erişilebilirlik tarafı ve hassas konular

Sesli arayüzün en güçlü olduğu yer, ekranla kurulan ilişkinin zaten zor olduğu yer. Görme engelli kullanıcı için ekran okuyucuyla sayfada gezinmek yerine soruyu doğrudan sorup cevabı almak ciddi bir kısalma. Konuşma arayüzlerinde erişilebilirlik önerileri bu tarafta iyi bir başlangıç noktası.

Testin kendisinde bir de etik taraf var. Ask GeorgiaGov gibi kamu içeriğinde kullanıcı boşanma, taciz, sosyal yardım gibi konuları sesli soruyor, üstelik odada bir moderatör varken. Bu senaryolarda katılımcıya görevi atlama hakkını baştan vermek, veri kalitesini düşürmez; tersine, konuyu sesli sormaktan çekinen kullanıcının davranışını da görünür kılar.

Sessiz ortam, tek tek oturumlar ve kaydın ham tutulması sesli testi ekran testinden pahalı yapar. Bu yüzden testi geç ve büyük değil, erken ve küçük yapmak gerekiyor: beş kişiyle yapılan bir oturum, diyalog akışındaki yanlış varsayımı zaten ortaya çıkarır.