Konu Başlıkları
Yükleniyor...

Sesli İçerik ve Kullanılabilirlik: Asistan ile Ekran Okuyucu Aynı Şey Değil

Sesli Arayüzlerde İçerik Tasarımı: IVR, Ekran Okuyucu ve Asistan Farkı

Sesli arayüz denince akla önce Siri ve Alexa geliyor. Oysa sesin en olgun kullanımı yıllardır ekran okuyucularda, ve bu ikisi aynı şey değil: biri gezinilebilir bir arayüz, diğeri lineer bir konuşma. Ayrım netleşmeden verilen "sesli içerik kısa olsun" tavsiyesi çoğu zaman yanlış kullanıcıya yazılıyor.

Konuşmanın makineye geçmeyen kısmı

Konuşma insanın en eski iletişim biçimi, ama düzensizliğiyle eski. Cümleyi ortasında keseriz, geri döneriz, aynı şeyi iki kez söyleriz. Yazı sabit durur, ses akar.

Bugün asıl zorluk kelimeleri tanımak değil; konuşma tanıma uzun süredir yeterince iyi. Zor olan, kelimelerin yanında taşınan şey. Ton, hız, duraklama, sorunun gerçekten soru mu yoksa itiraz mı olduğu. "Hayır, o değil" cümlesindeki bilginin çoğu kelimelerde durmuyor.

İnsanlar sesli arayüzü ne için açar

Michael McTear ve ekibi, konuşmaları üç sebeple başlattığımızı söylüyor: bir iş yaptırmak, bir bilgi almak, sosyalleşmek. Üçüncüsü sesli arayüzlerde pratikte yok. Asistanların şaka repertuvarı bir sohbet değil, demo malzemesi.

Geriye iki gerçek kullanım kalıyor. İşlemsel olanda kullanıcı bir sonuç istiyor: "Bir büyük pizza söyle." Bilgilendirici olanda bir cevap: "Glutensiz seçenek var mı?" Fark tasarıma doğrudan yansır. İşlemde kısa onaylar ve tek bir eksik bilgi sorusu yeter, cevabı uzatmak kullanıcıyı yorar. Bilgide ise kısalık zarar verir; yarım cevap alan kullanıcı soruyu baştan sormak zorunda kalır ve ikinci deneme her zaman ilkinden daha sinirlidir.

IVR'ı erken gömmeyin

IVR sistemleri genelde sesli arayüzlerin ilkel atası gibi anlatılır: menü ağacı, sabit komutlar, robot ses. Dar kapsamlı ve sık tekrar eden işlerde IVR'ı sesli asistandan daha güvenilir buluyorum, çünkü kapalı komut kümesi bir kusur değil bir sözleşme. Sistem size ne yapabildiğini baştan söylüyor.

Asistan bunun tersini yapar. Her şeyi anlayabilirmiş gibi davranır, anlamadığında kullanıcı hatanın nerede olduğunu bilemez. Telaffuz mu, cümle kuruluşu mu, yoksa o özellik hiç mi yok? Kullanıcıyı bilinmeyen bir sınırda deneme yanılmaya bırakmak, üç seçenekli bir menüden daha kötü bir deneyim.

Ekran okuyucu lineer değildir

Sesli içerik yazılarının çoğu şu varsayımla ilerler: metin taranabilir, ses taranamaz, o halde sesli ortamda içerik kısa olmalı. Bu cümlenin ilk yarısı ekran okuyucular için yanlış.

NVDA, JAWS ve VoiceOver kullanıcıları sayfayı baştan sona dinlemez. H tuşuyla başlıktan başlığa atlar, link listesi çıkarır, landmark'lar arasında gezer, konuşmayı normalin iki üç katı hızda dinler. Bu, gözle sayfa tarama davranışının sesli karşılığıdır. Yani sorun içeriğin uzunluğu değil, gezinilebilir olup olmadığı.

Sonuç ters yönde işliyor: sayfayı kırk tane anlamsız div ile kurup metni kısaltmak ekran okuyucu kullanıcısına yardım etmez, gezinme tutamağı bırakmadığı için içeriği gerçekten lineer hale getirir. Doğru başlık hiyerarşisi verilmiş uzun bir sayfa, yapısız kısa bir sayfadan çok daha hızlı tüketilir. Erişilebilirlik burada bir yazım işi değil, işaretleme işi.

Kısalık kimin için zorunlu

Sesli asistanda durum farklı, orada lineerlik gerçek. Geri sarma yok, başlık listesi yok, dinlediğiniz cevabın ortasına dönemezsiniz. Cevap tek seferde anlaşılmak zorunda ve çalışma belleğinin sınırı burada tavan koyar. Bir adres, bir saat, bir fiyat. Üç maddelik bir liste bile telefonda kalem aramaya başlatır insanı.

Aynı metnin her iki ortama birden hizmet etmesi beklentisi de bu yüzden zayıf. Asistan için yazılmış bir cevap, web sayfası olarak fakir kalır; sayfa için yazılmış bir paragraf sesli okunduğunda anlaşılmaz. İki ortam için iki metin yazmak, tek metni ikisine birden uydurmaya çalışmaktan daha ucuz çıkıyor.

Kısacası ses tek bir kanal değil. Ekran okuyucu için yapı kurulur, asistan için cümle kısaltılır, IVR için sınır dürüstçe söylenir. Bunları tek bir "sesli içerik" başlığı altında toplayan her tavsiye, üçünden en az ikisine yanlış gelir.

Kaynaklar