Prototip Türleri: Hangi Aşamada Hangi Nitelik İşe Yarar
Prototipin niteliği (fidelity), onun ne kadar iyi olduğunu değil ne kadar bitmiş göründüğünü anlatır. Kağıda çizilmiş bir ekran da tıklanabilir bir maket de aynı akışı gösterebilir, ama size çok farklı türde geri bildirim getirirler. Seçimi belirleyen şey bütçe değil, o hafta vermeniz gereken karar.
Düşük nitelik: asıl faydası ucuzluğu değil
Kağıt eskizler, storyboard'lar, defter köşesine çizilmiş üç ekran. Bunların avantajı genelde maliyetle açıklanır, oysa asıl mesele başka: atılabilir olmaları. Yarım saatte çizdiğiniz üç akıştan ikisini çöpe atmak kimseyi üzmez. Aynı üç akışı iki gün uğraşıp tıklanabilir hale getirdiyseniz, toplantıda onları savunmaya başlarsınız. Emek arttıkça fikri bırakmak zorlaşır, ve prototipin bütün amacı fikri kolay bırakabilmekti.
Kağıdın bedeli de var. Zamanlama, gecikme, kaydırma hissi, bir düğmeye bastıktan sonraki bekleme; hiçbiri kağıtta yok. Kullanıcı parmağını bir kutuya koyduğunda ne olacağını siz söylemek zorunda kalırsınız, o da testi sessizce yönlendirir.
Orta nitelik ve wireframe'in gerçek işi
Gri kutular, hiyerarşi, akış. Wireframe aşamasında en çok işe yarayan alışkanlık, sahte metni atıp gerçek içeriği koymaktır. Lorem ipsum her yere sığar; gerçek ürün adı, gerçek fiyat, gerçek hata mesajı sığmaz. Bir tasarımın en çok tartışılacak yeri, genellikle metnin taşıp iki satıra düştüğü yerdir, ve bunu ancak gerçek içerikle görürsünüz.
Bu aşamada görsel dili tartışmaya açmayın. Renk konuşulmaya başlandığı an akış konuşulmamaya başlar.
Yüksek nitelik ve dikkatin kayması
Gerçek renkler, gerçek tipografi, gerçek veri geldiğinde geri bildirim de oraya kayar. Kullanıcı "bu mavi biraz soğuk durmuş" der, akıştaki iki fazladan adımı kimse dile getirmez. Bu kullanıcının hatası değil; prototip neyi bitmiş gösteriyorsa insan onu sorgulamayı bırakır, cilalı olan yeri de yorumlar.
Yüksek nitelik gerçekten gerektiğinde bellidir: mikro etkileşimleri, animasyon sürelerini, algılanan hızı ölçüyorsanız başka yolu yok. Bir de paydaş ya da yatırımcı sunumu var, ki o test değil ikna işidir. İkisini aynı oturumda yapmaya çalışmak her ikisini de bozar.
"Kullanıcının kendi ortamında test edin" tavsiyesinin sınırı
Prototipleme rehberlerinin çoğu iki şeyi yan yana söyler: erken aşamada düşük nitelikli prototip kullanın, ve testi kullanıcının doğal ortamında yapın. Bu ikisi çoğu zaman aynı anda mümkün değildir. Kağıt prototip, sayfaları sizin çevirmenizi gerektirir; masa başında, moderatörün gözü önünde, tek bir işe odaklanmış bir kullanıcı üretir. Oysa karar verdiğiniz şey mobil bir akışsa gerçek koşul bunun tersidir: otobüste, tek elle, yarım dikkatle.
Çıkışı basit. Mobil için karar veriyorsanız düşük nitelik bile en azından telefon ekranında açılan, ekran görüntülerinin birbirine bağlandığı bir dosyaya dönüşmeli. Soru "hangi nitelik" değil, "hangi ortam" olmalı; nitelik ondan sonra gelir.
Test, karar, empati
Test için yapılan prototip tek bir soruya hizmet eder. "Kullanıcı filtreyi buluyor mu" gibi dar bir soru. Bütün ürünü prototiplemeye kalkarsanız elinizde ürünün kendisi olur, testin değil.
Karar için yapılan prototip ise tartışmayı bitirmek içindir. İki seçenek arasında üçüncü toplantıya girdiyseniz, her ikisini yarım gün içinde kabaca prototipleyip önüne koymak, tartışmayı bir hafta daha sürüklemekten ucuza gelir. Ekipte fikir ayrılığı uzuyorsa sorun genelde argümanların zayıflığı değil, ortada bakılacak somut bir şey olmamasıdır.
Empati için prototipleme kısmında dikkatli olmak gerekiyor. Görme engelini taklit eden gözlükler yaygın bir öneridir, ama birkaç dakikalık acemilik, yıllardır ekran okuyucu kullanan birinin ustalığıyla aynı şey değildir. Bu tür simülasyonlar erişilebilirlik alanında sık eleştirilir, çünkü çoğunlukla anlayış yerine acıma üretir ve tasarımcıyı "bu iş çok zormuş" noktasına bırakır. Otuz dakikalık gerçek bir kullanıcı görüşmesi, günlerce süren simülasyondan fazlasını verir.
Seçerken sorulacak soru
Bir prototipe başlamadan önce cevaplayın: bu görüldükten sonra hangi karar değişebilir? Cevap net bir karara işaret etmiyorsa prototipi yapmayın, çünkü yaptığınız şey prototip değil, erken üretim olur. Cevap "ekip bir görsün" ise elinizdeki bir sunumdur; sunum yapmak da meşru bir iştir, yeter ki onu test sanmayın.