Wireframe, mockup ve prototip farkı nedir?

Kısaca

Üçü de bir ekranı kodlamadan önce göstermenin yoludur. Aralarındaki fark, son ürüne ne kadar benzedikleridir. Buna sadakat (fidelity) denir.

Terimlerin tek tek tanımı sözlükte duruyor: wireframe ve prototip. Bu rehberde üçünün farkını ve hangisini ne zaman kullandığımı anlatıyorum.

Mockup nedir

Mockup, bir ekranın son ürüne benzeyen ama çalışmayan görüntüsüdür. Wikipedia mockup'ı genel anlamda bir tasarımın ya da cihazın ölçekli veya gerçek boyutlu modeli diye tanımlar. Yazılımdaki en yaygın kullanımı, son kullanıcıya yazılımın nasıl görüneceğini göstermektir.

Aynı maddeye göre yazılım mockup'ı gerçeğine benzer, ama görünenin ötesinde bir iş yapmaz. İşlevin en az bir kısmını sunup tasarımı test etmeye imkân verirse artık prototip sayılır. Benim kullandığım sınır da bu: tıklayınca bir şey oluyorsa prototiptir.

Ekipte kullandığım tanım şöyle: mockup, wireframe'deki yerleşimin renk, yazı tipi, gerçek metin ve görselle giydirilmiş durağan halidir. Bu tanım benim; kaynaklarda kelimenin sınırları bu kadar keskin çizilmiyor.

Mockup'ın sadakati de değişir. Laubheimer'ın anketinde ayrı bir kalem olarak "pixel-perfect" mockup geçiyor. Adı, son ekranla piksel piksel aynı bir çizimi anlatıyor. Ben çoğu projede bu kadar ileri gitmem; renk ve yazı tipi kararını verdirecek kadar ayrıntı yeterli.

Fark tablosu

NN/g'den Kara Pernice sadakati tek bir ölçü olarak görmez. Ona göre sadakat etkileşimde, görselde ve içerikte ayrı ayrı yüksek ya da düşük olabilir. Tablodaki her hücreyi bir eğilim olarak okuyun.

Ölçüt	Wireframe	Mockup	Prototip
Sadakat	Düşük. Gri kutular ve birkaç etiket.	Görselde yüksek, etkileşimde yok.	Etkileşim var. Kâğıt da olabilir, son ürüne çok yakın bir dosya da.
Amaç	Öğelerin yerini ve sırasını konuşmak.	Renk ve yazı tipi gibi görsel kararları onaylatmak.	Akışı kullanıcıyla denemek.
Araç	Kâğıt ve kalın uçlu kalem ya da bir tasarım aracında gri kutular.	Tasarım aracı, tasarım sistemi bileşenleri, gerçek görseller.	Tasarım aracında ekranları bağlamak, kâğıt prototip ya da kod.
Kim için	Ekip içi konuşma ve geliştiriciler.	Çoğunlukla dış müşteri.	Test katılımcıları, geliştiriciler ve müşteri.
Süre	En kısa. Yanlışsa silip yeniden çizersiniz.	Orta. Her görsel karar zaman alır.	En uzun. Ekranları birbirine bağlamak da iş.

Süre satırı kendi deneyimime dayanıyor. Saat vermiyorum, çünkü ekranın büyüklüğüne ve ekibin hazırlığına göre çok değişiyor. Pernice de tıklanabilir bir prototip hazırlamanın zaman alabildiğini yazıyor.

"Kim için" satırı bir ankete dayanıyor. Page Laubheimer'ın NN/g için 86 UX uzmanıyla yaptığı 2015 anketinde statik wireframe en sık üretilen çıktıydı. Katılımcıların %71'i onu "sık" ürettiğini söyledi.

Aynı ankette piksel piksel bitmiş mockup'lar yalnızca dış müşterilerle etkili bulundu. Müşteri işinde katılımcıların %47'si mockup'ı seçti, yöneticilere fikir anlatmada ise yalnızca %25'i. Müşteri işinde mockup'ın önünde tek bir çıktı vardı: %67 ile tıklanabilir prototip.

Geliştiricilerle çalışırken de en etkili çıktı tıklanabilir prototipti. Statik wireframe bu listede ilk beşe girdi.

Aynı ekran, üç sadakat seviyesi

Aşağıdaki örnek, bir ulaşım kartına bakiye yükleme ekranı. Yerleşim üç halde de aynı. Değişen tek şey sadakat.

Aynı ekran, üç sadakat

1. Wireframe

tutar

50100200

Yükle

2. Mockup

←Kart bakiyesi

Ulaşım kartı •••• 4821

Bakiye

42,50 TL

Yüklenecek tutar

50 TL100 TL200 TL

100 TL yükle

Görüntü Butonlar çizim, basınca bir şey olmaz.

3. Prototip

JavaScript kapalı olduğu için iki ekran alt alta görünüyor.

←Kart bakiyesi1 / 2

Ulaşım kartı •••• 4821

Bakiye

42,50 TL

Yüklenecek tutar

50 TL 100 TL 200 TL

100 TL yükle

Yükleme2 / 2

100 TL yüklendi

Yeni bakiye: 142,50 TL

Dekont e-posta adresinize gönderildi.

Başa dön

Kart, tutarlar ve bakiye uydurmadır. Üstteki seçiciyle aynı ekranın üç halini değiştirin; ok tuşlarıyla da geçebilirsiniz. Prototipte tutarı seçip yükle butonuna basınca ikinci ekran açılır. JavaScript kapalıysa üç hal alt alta görünür.

Her aşamada başka bir soru sorarım. Wireframe'de: tutar seçimi butondan önce mi duruyor? Mockup'ta: kartın üstündeki bakiye rahat okunuyor mu?

Prototipte ise kullanıcıyı izlerim. Tutarı değiştirmeden butona basıyor mu, ikinci ekranda bakiyenin arttığını fark ediyor mu? Bu soruların cevabı ancak tıklanan bir ekranda görünür.

Bu yüzden önce soruyu yazarım, sonra sadakati seçerim. Sırayı tersine çevirince ekip cevabını zaten bildiği şeyleri cilalamaya başlıyor.

Ne zaman hangisi

Wireframe: yapı henüz belli değilse

Ekranda hangi öğenin olacağı ve sırası tartışılıyorsa wireframe'le başlarım. Gri bir kutuyu silmek ucuzdur ve kimse rengi konuşmaz. Menü ve sayfaların yerleşimi, yani bilgi mimarisi belliyse bu adım hızlı geçer.

Kelley Gordon (NN/g) wireframe için kalın uçlu kalem ve süre sınırı öneriyor. İkisi de küçük görsel ayrıntılara takılmanızı engelliyor.

Mockup: görünüş onay bekliyorsa

Marka rengi ve yazı tipi karara bağlanacaksa mockup gerekir. Kontrast ve okunabilirlik de ilk kez bu aşamada görünür. Renkler ve bileşenler bir tasarım sisteminden geliyorsa mockup aşaması kısalır.

Prototip: akışı test edecekseniz

Kullanıcının bir işi baştan sona bitirip bitiremediğini görmek istiyorsanız prototip gerekir. Kullanılabilirlik testi bu malzemeyle yapılır. Kaç kişiyle deneyeceğinizi kaç kullanıcıyla test rehberinde anlattım.

Pernice'ye göre bitmiş ürünü test etmek risklidir. Kodu söküp atmak pahalıdır, kâğıttan bir prototipi yırtmak ise değildir.

Bir örnekle: sepet sayfası

Diyelim ki bir e-ticaret sitesinin sepet sayfasını yeniden tasarlıyorsunuz. İlk soru yapıyla ilgili: kargo ücreti ürün listesinin üstünde mi duracak, altında mı? Bunu wireframe'de konuşursunuz, iki ya da üç versiyonu yan yana çizip karşılaştırırsınız.

Yerleşim oturunca mockup'a geçersiniz. İndirim kodu alanı fazla mı göze batıyor, toplam tutar yeterince büyük mü? Bunlar renk ve yazı boyutuyla ilgili sorular.

Son adımda prototiple kullanıcıya bir görev verirsiniz: "Sepetteki ikinci ürünü silip ödemeye geçin." Kullanıcı sil butonunu bulamıyorsa bunu durağan bir çizim size göstermezdi. Ödeme adımının kendisini checkout kalıbı sayfasında ayrıca anlattım.

Sadakati seçerken sorduğum sorular

Bir ekran üzerinde çalışmaya başlamadan önce kendime birkaç soru sorarım. Cevaplar çoğu zaman sadakati kendiliğinden seçer.

1. Bu hafta neyi öğrenmem gerekiyor? Yerleşim tartışılıyorsa wireframe, görünüş tartışılıyorsa mockup, akış tartışılıyorsa prototip.
2. Kime göstereceğim? Ekip içinde konuşulacaksa kaba çizim yeter. Dış müşteri onay verecekse görünüş de önem kazanır.
3. Yanlış çıkarsa neyi atacağım? Atacağım şey ne kadar pahalıysa o kadar kaba başlarım.
4. Bileşenler hazır mı? Tasarım sistemi varsa yüksek sadakat ucuzlar. Yoksa her ekran sıfırdan çizilir ve mockup uzar.
5. Kullanıcı ekranı nerede görecek? Telefonda kullanılacak bir akışı masaüstü ekranında test etmek beni yanıltır. Prototipi kullanıcının kendi telefonunda açarım.

Bu listeyi her projede aynen uygulamam. Ama ilk iki soruya cevap veremiyorsam henüz hiçbir şey çizmem.

Bu sıra şart mı

Değil. Wikipedia'daki mockup maddesi de yazılım ve sistem mühendisliğinde bu üç kavramın birbirinden net ayrılmadığını söylüyor. Bana mantıklı geliyor, çünkü sadakat tek bir çizgi üzerinde ilerlemiyor.

Kâğıda çizdiğiniz wireframe'leri sırayla gösterirseniz düşük sadakatli bir prototipiniz olur. Mockup'ları birbirine bağlarsanız yüksek sadakatli bir prototip elde edersiniz. İkisi de prototiptir; farkları görsel eksende.

Bazen mockup'ı tamamen atlarım. Ürünün oturmuş bir tasarım sistemi varsa bileşenler zaten renkli ve hazırdır. O zaman wireframe'den doğrudan tıklanabilir prototipe ya da koda geçerim.

Tersi de olur. Görsel dili henüz belirlenmemiş yeni bir markada mockup'ı erkene alırım. Renkler ve görseller ekipte uzun tartışma çıkarıyorsa, bu tartışmayı yerleşim kararlarından ayırmak işimi kolaylaştırır.

Sık yapılan hatalar

• Erken mockup. Yerleşim konuşulmadan renkli ekran gösterilirse toplantı renge kayar. Pernice'ye göre kullanıcılar kaba bir tasarımı daha rahat eleştirir. Ben aynısını paydaş toplantılarında da görüyorum.
• Mockup'la akış testi. Durağan bir görselde kullanıcıya "buraya basınca ne olur?" diye sorarsınız. Ölçtüğünüz şey onun tahmini olur. Akışı görmek için ekranları birbirine bağlayın.
• Testten önce her ekranı cilalamak. Pernice, tasarımcıların düşük sadakatli prototiplere daha az bağlandığını yazar. Test kötü çıktığında cilalı bir ekrandan vazgeçmek daha zor geliyor.
• Geliştiriciye yalnızca mockup vermek. Durağan görüntü, butona basınca ne olacağını ve hata halini göstermez. Geliştirici bunları tahmin etmek zorunda kalır. Hata mesajlarını da ekran olarak çizin.

Benim notum

Audit'lerde incelediğim ekranların çoğu, wireframe aşamasını hiç yaşamamış gibi duruyor. Renkler ve görseller özenli, ama öğelerin sırası kullanıcının işine uymuyor. Sorunun kaynağı genelde atlanan ilk adım.

Benim varsayılan sıram şöyle: kâğıtta wireframe, tasarım sistemiyle tıklanabilir prototip, kısa bir test, sonra kod. Mockup'ı ayrı bir adım olarak yalnızca görünüşü onaylayacak biri varsa yaparım. Laubheimer'ın anketi de mockup'ın en çok dış müşteride işe yaradığını gösteriyor.

Tasarımı ve kodu aynı kişide toplamak bu sırayı kısaltıyor. Tasarla & Yayınla Sprinti bunun için var: iki haftada wireframe'den reponuzdaki çalışan ekrana. Elinizde canlı bir ürün varsa önce UX Audit ile kullanıcının nerede takıldığına bakmak daha ucuz.