Kâğıt Prototipleme Neyi Test Eder, Neyi Etmez
Kâğıt prototip, ekranı kodlamadan önce akışı kullanıcının eline vermenin en ucuz yolu. Ucuzluğu onu her soru için uygun yapmıyor: bir kısım soruya net cevap verir, bir kısmında düpedüz yanıltır. İkisini ayırmak, yöntemin kendisinden daha belirleyici.
Kâğıdın gerçekten ölçtüğü şeyler
Elle çizilmiş bir ekran, kullanıcının kafasındaki modelle sizinkini karşılaştırır. Bir görev verirsiniz, kullanıcı kâğıda bakar ve parmağını bir yere koyar. O parmağın nereye gittiği, sizin kurduğunuz sıranın onun beklediği sırayla uyuşup uyuşmadığını söyler.
Bu düzeyde şunlar test edilebilir: adımların sırası, etiket ve buton metinlerinin anlaşılırlığı, bir öğenin tıklanabilir görünüp görünmediği, kullanıcının bir sonraki adımı ekranın neresinde aradığı. Hepsi kâğıda sığıyor çünkü hepsi anlam meselesi, zaman meselesi değil.
Kâğıdın ölçemediği şeyler
Kâğıt prototipte bilgisayarı bir insan oynatır. O insan hiç gecikmez, hiç yanlış anlamaz, istenen kartı her seferinde doğru çıkarır. Gerçek yazılımın en çok sorun çıkardığı yerler tam da bu yüzden görünmez kalır: bekleme durumları, hata mesajları, yarım kalmış form, düşen oturum.
İkinci kör nokta veri hacmi. A4'e çizilen liste altı satırdır ve her tasarım altı satırda iyi görünür. Aynı ekran üç yüz satırla, taşan ürün adlarıyla ve hiç sonuç dönmeyen haliyle denenmedikçe, onaylanan şey tasarım değil çizimin kendisi olur.
Kaydırma da kâğıtta kayboluyor. Katlanmış bir sayfayı parmakla aşağı çekmek, kullanıcının ekranda sayfanın devamını aramasının yerini tutmuyor.
Bir turun işleyişi
Kâğıt prototipleme bir çizim tekniği değil, test tekniği. Turu kuran dört adım şu:
- Akışı seçin, ekranı değil. Test edilen şey “sepet sayfası” değil, “kuponu uygulayıp ödemeye geçmek”.
- Akışın geçtiği ekranları ayrı kâğıtlara çizin. Menü, açılır pencere, hata kutusu gibi üstte beliren parçaları küçük ayrı kâğıtlara alın; test sırasında ana sayfanın üzerine koyacaksınız.
- Görevi verin ve susun. Yönlendirme başladığı anda ölçtüğünüz şey tasarım olmaktan çıkar.
- Duraksamaları kaydedin. Yanlış dokunuştan çok, dokunuştan önceki iki saniyelik tereddüt işinize yarar.
Test sırasında kâğıtları çeviren kişiyle not tutan kişiyi ayırmayı tercih ederim. Tek başına ikisini üstlenince hep aynı şey oluyor: kullanıcı duraksarken siz doğru kartı arıyorsunuz ve o duraksamayı hiç kaydetmiyorsunuz. Oysa aradığınız veri tam olarak o.
“Kod yazılmadan değiştirmek yüz kat ucuz” derken
Bu rakam bir yerden geliyor: Barry Boehm'ün 1981 tarihli yazılım maliyeti çalışması. Oradaki veriler şelale modeliyle yürüyen, sürümü yılda bir çıkan büyük projelere ait. Yüz katı iki haftalık sürüm döngüsüne olduğu gibi taşımak doğru olmuyor, kaynak gösterilmeden tekrarlanması da iddiayı zayıflatıyor.
Yönü yine de doğru, ama sebebini görmek gerekiyor. Geç kalan değişikliği pahalı yapan, kodu yeniden yazmak değil. Kodun etrafında donmuş kararlar pahalı: veritabanı şeması, dışarıya verilmiş API sözleşmesi, yazılan testler, üstüne kurulmuş raporlar. Kâğıttaki bir akış değişikliğinin bunlardan hiçbiri yok, karşılığı yeni bir çizim.
Kâğıdı ne zaman bırakmalı
Ayrım sorulardan geçiyor. “Kullanıcı bu adımı buluyor mu” sorusu kâğıtta cevaplanır. “Bu adım fazla mı uzun geliyor”, “liste dolduğunda hâlâ okunuyor mu”, “bağlantı koptuğunda ne oluyor” soruları kâğıtta cevaplanmaz, sadece cevaplanmış gibi görünür. Bunlar masaya geldiğinde tıklanabilir bir prototipe ya da gerçek veriyle çalışan kaba bir sürüme geçmek gerekir.
Pratikte iki üç tur çoğu akış için yetiyor. Üçüncü turda gelen geri bildirimler çizimin kendisine dönmeye başladıysa, kâğıdın verebileceği bitmiş demektir.