Wireframe ve Prototip: Sadakat Düzeyini Teste Göre Seçmek
Wireframe ile prototipi ayıran şey detay miktarı değil, cevapladıkları soru. Wireframe "bu ekranda ne nerede duruyor" sorusuna bakar, prototip "kullanıcı buradan oraya gidebiliyor mu" sorusuna. Sadakat düzeyini teste göre seçmediğinizde, oturumdan renk ve font yorumlarıyla çıkar, asıl akış sorununu kaçırırsınız.
Düşük sadakat bir eksiklik değil
Gri kutulardan ibaret bir ekranı test kullanıcısına gösterdiğinizde rahatça eleştirir. Bitmemiş görünen bir şeye laf söylemek kimseye ağır gelmez. Aynı akışı gerçek fotoğraflar, marka rengi ve son tipografiyle sunduğunuzda gelen cevap çoğunlukla "güzel olmuş" oluyor, çünkü karşısındakinin haftalarca uğraştığını görüyor.
Bu yüzden wireframe aşamasında kasıtlı olarak çirkin kalmakta fayda var. Görsel yerine çapraz çizgili kutu, metin yerine gerçek uzunlukta düz metin. Lorem ipsum bile fazla nazik: gerçek ürün adları ve gerçek başlık uzunlukları kullanın, çünkü düzenin ilk kırıldığı yer "Kampanya" yazan düğmenin "Kampanyalı Ürünleri Görüntüle" olduğu andır.
Prototipin maliyeti ekran sayısıyla değil, bağlantı sayısıyla artar
Tıklanabilir prototipin cazibesi, gerçek uygulamanın yerine geçebilecek kadar ilerletilebilmesi. Sorun da tam olarak bu. On iki ekranlı bir akışta her ekrana beş maddelik bir menü koyup her maddeyi bağlarsanız 60 ok çizmişsiniz demektir. Menüye tek bir madde eklendiğinde 12 ok daha eklersiniz, bir ekranın adı değişince onlarca yerde kontrol edersiniz. Ekran sayısı doğrusal artar, bakım yükü çarpım halinde.
Pratik karşılığı şu: prototipi uygulamanın maketi olarak değil, tek bir görevin patikası olarak kurun. "Sepete ekleyip ödemeyi tamamla" yedi ekransa yedi ekranı bağlayın, menüyü ölü bırakın. Test sırasında kullanıcı menüye tıklarsa zaten öğrendiğiniz bir şey var: görev sizin tasarladığınız yoldan gitmiyor.
Bileşen içine gömülen etkileşimler bu yükü ciddi biçimde azaltıyor, menüyü tek bir bileşende bağlayıp her yerde kullanmak mümkün. Yine de bileşen hiyerarşisini kurmanın kendi maliyeti var ve iki günlük bir test için buna girmeye değmiyor.
Araç seçiminde işe yarayan iki eksen
Araç karşılaştırması genelde özellik listesi sayarak yapılıyor, oysa karar iki soruda bitiyor: dosya kimde duracak ve prototipin koşullu mantığa ihtiyacı var mı?
Birinci soruda Figma'nın tarayıcıda çalışması ve aynı dosyada eş zamanlı düzenlemeye izin vermesi belirleyici. Müşteriye link atıp yorumu tasarımın üstünde toplayabiliyorsanız, e-posta ekindeki "final_v7_son.sketch" trafiği ortadan kalkıyor. Sketch güçlü bir vektör aracı ama macOS'a bağlı ve paylaşım için ayrı bir katman gerektiriyor; InVision'ın uzun süre yanında anılmasının sebebi de bu boşluğu doldurmasıydı. Adobe XD'yi tercih etmek için makul gerekçe, ekibin zaten Photoshop ve Illustrator üzerinden akan bir üretim hattı olması.
İkinci soru daha az sorulan ama daha çok zaman kaybettiren soru. Axure RP, değişken tutabildiği ve koşul yazabildiği için form doğrulaması, filtrelenen tablo, oturum durumuna göre değişen ekran gibi şeyleri gerçekten simüle edebiliyor. Buna ihtiyacınız varsa alternatifi yok. Ama prototipinizde "eğer" cümlesi kurmaya başladığınız noktada dürüst bir soru daha var: aynı davranışı basit bir HTML sayfasıyla kurmak daha mı ucuz olurdu? Tarayıcıda çalışan bir taslak, gerçek klavye, gerçek kaydırma ve gerçek gecikmeyle test edilir. Ekiplerin çoğunun Axure'e ihtiyacı yok, ihtiyacı olanların çoğu da aslında koda bir adım daha yakın durmalı.
Beş kullanıcı kuralı ve nerede kırıldığı
Prototipi kaç kişiyle test etmek gerektiği sorusunun standart cevabı beş. Bu sayı keyfi değil, basit bir olasılık hesabından geliyor: bir kullanıcının rastgele bir kullanılabilirlik sorununu bulma ihtimaline L dersek, n kullanıcıyla bulunan sorun oranı 1-(1-L)^n. Nielsen Norman Group'un ölçtüğü ortalama L değeri 0,31 ve beş kullanıcı için hesap yaklaşık %84 veriyor. Onuncu kullanıcı bu oranı ancak %97'ye taşıyor, yani ikinci beş kişiye ödediğiniz para ilk beş kişinin altıda biri kadar bulgu getiriyor. Ayrıntı için NN/g'nin yazısı hâlâ en net kaynak.
Kuralın atlanan kısmı formülün varsayımı. Hesap, tek ve homojen bir kullanıcı grubu olduğunu kabul ediyor. Bayinin panel kullandığı, son müşterinin vitrini gezdiği bir üründe iki ayrı davranış evreni var ve beş kişilik örneklem ikiye bölündüğünde kimseyi temsil etmiyor. Böyle bir durumda her grup için ayrı ayrı üçer dörder kişi, tek gruptan yedi kişiden daha çok şey söylüyor.
İkinci atlanan kısım daha can sıkıcı: formül sorunun bulunmasını sayıyor, düzeltilmesini değil. Beş kişilik tek bir tur yapıp raporu klasöre koyan ekiple hiç test yapmayan ekip arasında pratikte fark yok. Sayının küçük tutulmasının asıl amacı da bu, ucuz olsun ki tekrarlanabilsin.
Wireframe'i ne zaman atlıyorum
"Her projede wireframe şart" cümlesi, wireframe'in zaman kazandırdığı iddiasıyla çelişiyor. Beş sayfalık bir kurumsal tanıtım sitesinde düzen zaten belli: üstte menü, altta iletişim, arada içerik. Buraya ayrı bir wireframe turu koymak, aynı kararı iki kez almak demek. Metni toplayıp doğrudan tasarıma geçmek daha hızlı ve genelde daha iyi sonuç veriyor, çünkü asıl belirsizlik düzende değil içerikte.
Wireframe'in bedelini fazlasıyla çıkardığı yerler ise şunlar: çok adımlı formlar, ekranın yarısını dolduran tablo ve filtreler, daha önce yapmadığınız bir akış, bir de kararın iki kişiden fazlasına onaylatılması gereken her durum. Sonuncusu teknik değil siyasi bir sebep ama en çok zaman kazandıranı o. Gri kutuların üstünde tartışmak, hazır tasarımın üstünde tartışmaktan hem ucuz hem de daha az kırıcı.