Prototip Testinde Sadakat Seviyesi Neyi Ölçer, Neyi Ölçmez

Prototip sadakati tartışması genelde maliyet tartışması gibi kurulur: düşük sadakat hızlı ve ucuz, yüksek sadakat yavaş ve pahalı. Oysa seçimi belirleyen şey maliyet değil, prototipin hangi soruyu cevaplayabildiği. Sadakat seviyesi değişince kullanıcının konuştuğu konu da değişiyor, çoğu ekip bunu testin ortasında fark ediyor.

Sadakat arttıkça geri bildirimin konusu değişir

Yüksek sadakatli prototipin daha güvenilir geri bildirim verdiği sık söylenir. Bu, sorunun ne olduğuna göre ya doğru ya da yanıltıcı. Elde çizilmiş bir ekran gösterdiğinde insanlar yapıyı tartışır: bu buton neden burada, bu adımdan sonra ne bekliyorum, listede aradığımı nasıl bulacağım. Gerçek metni, gölgesi ve ikonları yerleşmiş bir ekran gösterdiğinde yorumlar yüzeye kayar. Renk, boşluk, ikon seti, yazı tipi. Aynı kullanıcı, aynı akış, bambaşka bir konu.

İkinci etki prototipin kendisinde değil ekipte. Yüksek sadakatli prototipe harcanan emek, onu atma isteğini düşürür. Kırk saat verilmiş bir akışı test sonrası çöpe atan ekip azdır; onun yerine akış korunur, bulgular “ileride bakılacak” listesine yazılır.

Pratik sonuç: yüksek sadakatli prototipi gerçek kodla kurmaya kalkma. O kodun sonradan atılması gerekir, atılmaz, prototipin geçici kararları ürünün kalıcı kararına dönüşür.

Kağıt prototipin ölçemediği şey: durum

Kağıt prototip ekranları sırayla gösterir, dolayısıyla akışın yalnızca mutlu yolunu test eder. Ürünlerin çoğu mutlu yolda kırılmaz. Hatalı girilmiş bir form, yarı yolda kesilen bağlantı, beş satır beklenirken iki bin satır dönen bir liste, iki sekmede açılmış aynı kayıt: arayüzün zor kararları bunlarda veriliyor ve hiçbiri kağıtta görünmüyor.

Bu yüzden kağıt prototipten çıkan “akış anlaşılıyor” sonucunu “arayüz çalışıyor” diye okumamak gerekir. İlk testi kağıtla yapmak doğru; hata ve bekleme durumlarını da aynı testte gördüğünü sanmak değil. Durum geçişlerini bir yerde yazılı tut, ekran listesi bunu göstermez.

Wizard of Oz yönteminin gizli değişkeni

Arka uç hazır değilken kullanıcının isteğine perde arkasından bir insanın cevap verdiği düzen, dil ve niyet testlerinde gerçekten işe yarar. Kullanıcı ne yazıyor, nasıl soruyor, dönen cevabı anlıyor mu: bunlar ölçülebilir.

Ölçülemeyen şey süre. Yanıt gecikmesi orada sistemin değil operatörün yazma hızıdır, ve insan gecikmesi yavaş olmaktan kötüsü, tutarsızdır. Bir oturumda üç saniye, diğerinde on iki. Bekleme toleransını, algılanan hızı ya da zaman aşımı davranışını bu kurulumla test ettiğini düşünen ekip, kendi operatörünü ölçmüş olur. Yöntemin ikinci sınırı ölçek: her oturum bir operatör tutar, beş kullanıcıda makul, otuzda değil.

Hangisini seçeceğine karar vermek

Cevaplanması gereken tek soru şu: test edilen hipotez görünüşe mi bağlı, yapıya mı?

Yapıya bağlıysa, yani soru kullanıcının adımı bulup bulmadığı ya da sırayı anlayıp anlamadığıysa, erken aşamada düşük sadakat neredeyse her zaman daha iyi sonuç verir. Daha hızlı olduğu için değil, doğru konuyu konuşturduğu için.

Ama hipotezin kendisi algı hakkındaysa düşük sadakat hiçbir şey söylemez. Ödeme ekranı, kimlik doğrulama, sağlık verisi isteyen bir form: burada test edilen şey güven. Kullanıcı kağıt parçasına kart numarası yazmaktan çekinmez, gerçekçi ama acemi görünen bir ekrandan çekinir. O testte görsel bitmişlik süs değil, ölçülen şeyin parçası.

Arada geniş bir alan kalıyor. Akış doğru ama tıklanabilirliğin kendisi soru işareti ise tıklanabilir wireframe yeter: gri kutular, gerçek metin, gerçek geçişler, görsel tasarım yok.

Oturumu yürütürken

• İlk oturumu veri olarak değil prova olarak harca. Prototip genelde hiç düşünülmemiş bir yerde tıkanır ve o oturumun geri kalan soruları boşa gider.
• Prototipin bitmemiş olduğunu baştan söyle. Tek cümle yeter, özür cümlesine dönüşmesin.
• Kullanıcı tıkandığında kurtarma dürtüsüne direnme konusunda katı ol. Tıkanma, testin bulduğu şeyin kendisi; yalnızca oturum tamamen durduğunda müdahale et.