Mockup mı Prototip mi? Tasarımda Görünüm ile Davranışın Ayrımı

İki kavramı ayıran tek soru: Ekran tıklanabiliyor mu?

Mockup, bir arayüzün son haline yakın görünümünü gösteren durağan bir tasarımdır. Renkler, tipografi, ikonlar, görseller, boşluklar ve gerçek ya da gerçeğe yakın metinler yerindedir; ama ekran bir resim gibidir. Butona basıldığında hiçbir şey olmaz, ekranlar arasında geçiş yoktur.

Prototip ise ürünün davranışını taklit eden etkileşimli bir modeldir. Kullanıcı bir butona dokunduğunda başka bir ekrana geçer, bir menü açılır, bir form hata mesajı verir. Prototip kâğıt üzerinde kaba bir çizimle de yapılabilir, görsel açıdan son ürünle ayırt edilemeyecek kadar cilalı da olabilir. Onu prototip yapan görünüm değil, akışı deneyimletmesidir.

Bu yüzden iki kavram aynı eksen üzerinde durmaz. Mockup görsel doğruluk (fidelity) eksenindedir; prototip etkileşim eksenindedir. Bir mockup'a bağlantılar eklenip tıklanabilir hale getirildiğinde ortaya yüksek doğruluklu bir prototip çıkar. Pratikte sık rastlanan karışıklık da buradan doğar: Ekipler cilalı ekranlara "prototip" der, oysa ekranlar arasında hiçbir geçiş tanımlanmamıştır.

Ortak zemin: Kodlamadan önce karar vermenin araçları

Her ikisi de geliştirme ekibine iş verilmeden önce fikirleri ucuz yoldan sınamak için üretilir. Kod yazıldıktan sonra yapılan değişiklik hem zaman hem de ekip motivasyonu açısından pahalıdır; tasarım dosyasındaki değişiklik ise görece hızlıdır.

İkisi de aynı araçlarda hazırlanabilir. Figma, Sketch, Adobe XD ve Penpot gibi tasarım araçları hem durağan ekran tasarımına hem de ekranlar arası bağlantı kurmaya izin verir. Bu nedenle mockup ile prototip arasındaki fark çoğu zaman aynı dosyada, birkaç bağlantı ve etkileşim tanımı kadar uzaktadır.

Ortak bir sınırları da vardır: Hiçbiri gerçek ürün değildir. Mockup'ta görülen her şey teknik olarak yapılabilir olmayabilir; prototipte akıcı görünen bir geçiş, gerçek verinin gecikmesiyle karşılaştığında aynı hissi vermeyebilir. İkisi de bir varsayımı görünür kılar, doğrulamaz.

Ölçüt ölçüt mockup ve prototip

• Temel amaç: Mockup / ürünün nasıl görüneceğini kararlaştırmak. Prototip / ürünün nasıl çalışacağını ve kullanıcının akışı tamamlayıp tamamlayamadığını görmek.
• Etkileşim: Mockup / yok, ekranlar durağandır. Prototip / tıklama, kaydırma, geçiş, form davranışı gibi etkileşimler tanımlıdır.
• Görsel doğruluk: Mockup / yüksektir, renk, tipografi ve görseller son hale yakındır. Prototip / düşükten yükseğe herhangi bir düzeyde olabilir.
• Yanıtladığı soru: Mockup / "Bu marka ve bu düzen doğru mu, hiyerarşi okunuyor mu?" Prototip / "Kullanıcı ödeme adımına ulaşabiliyor mu, nerede takılıyor?"
• Asıl izleyici: Mockup / paydaşlar, marka ekibi, onay veren yöneticiler, geliştiriciler. Prototip / test katılımcıları, ürün yöneticisi, geliştiriciler.
• Test türü: Mockup / tercih testi, ilk izlenim testi, görsel hiyerarşi değerlendirmesi. Prototip / görev tabanlı kullanılabilirlik testi.
• Hazırlık emeği: Mockup / görsel ayrıntı ister, akış ister değil. Prototip / akışın her dalını tanımlamayı, hata ve boş durumları düşünmeyi gerektirir.
• Geliştiriciye aktardığı bilgi: Mockup / ölçüler, renkler, bileşen görünümü. Prototip / durumlar, geçişler, koşullu davranışlar.

Mockup hangi durumda doğru araç?

Mockup, kararın görünüm üzerine olduğu yerde işe yarar. Bilgi mimarisi ve akış wireframe aşamasında netleşmiştir; şimdi sıra markanın arayüze nasıl yansıyacağındadır.

• Yeni bir görsel kimliğin ürüne uygulanmasında paydaş onayı almak.
• Birkaç renk ya da düzen alternatifini yan yana koyup karşılaştırmak.
• Pazarlama ekibine, yatırımcıya ya da müşteriye ürünün son halini hayal ettirmek.
• Tasarım sisteminde yeni bir bileşenin farklı durumlarını belgelemek.
• Geliştiriciye piksel ölçüleri ve stil özelliklerini teslim etmek.

Örneğin bir bankanın mobil uygulamasında hesap özeti ekranı yeniden tasarlanıyorsa, bakiyenin mi yoksa son işlemlerin mi öne çıkacağı sorusu önce mockup üzerinde tartışılır. Bu tartışma için ekranların birbirine bağlanması gerekmez.

Prototip hangi durumda doğru araç?

Prototip, kararın davranış üzerine olduğu yerde gereklidir. Kullanıcının bir görevi baştan sona yürütmesi gerekiyorsa durağan ekranlar yetmez; çünkü insanlar akışın içindeyken, ekranlara tek tek bakarken fark etmedikleri sorunları yaşar.

• Kayıt, ödeme, başvuru gibi birden fazla adımdan oluşan akışları kullanıcıyla test etmek.
• Bir etkileşim fikrinin (kaydırarak silme, sürükle bırak, açılır panel) anlaşılır olup olmadığını görmek.
• Geliştiricilere bir animasyonun ya da geçişin nasıl hissettirmesi gerektiğini anlatmak.
• Hata mesajlarının, boş ekranların ve yükleme durumlarının akış içinde nasıl göründüğünü sınamak.

Örneğin bir e-ticaret sitesinde sepet terkini azaltmak için ödeme adımları birleştirilecekse, yeni akış prototip olarak hazırlanır ve birkaç kullanıcıya "bu ürünü satın alın" görevi verilir. Kullanıcının adres formunda duraksaması, mockup üzerinde hiçbir zaman görülemeyecek bir bulgudur.

Doğru sıra ve birlikte kullanım

Tipik bir UX sürecinde sıra şöyledir: Önce kaba eskizler ve wireframe ile bilgi mimarisi kurulur, ardından düşük doğruluklu bir prototip ile akış erken test edilir, akış oturduktan sonra mockup ile görsel dil uygulanır, son olarak bu mockup'lar bağlanarak yüksek doğruluklu prototip haline getirilir ve tekrar test edilir.

Bu sıranın mantığı, pahalı işi kararlar oturduktan sonra yapmaktır. Görsel ayrıntıya erken yatırım yapılırsa iki sorun çıkar: Test katılımcıları akış yerine renklere yorum yapar, ekip de emek verdiği ekranları değiştirmekte isteksiz davranır.

Yine de sıra katı değildir. Var olan bir tasarım sistemiyle çalışan ekipler, bileşenler hazır olduğu için doğrudan yüksek doğruluklu prototip üretebilir. Tersine, yalnızca bir ekranın görsel güncellemesi söz konusuysa prototipe hiç gerek kalmayabilir.

Sık yapılan hatalar ve nasıl önlenir

• Mockup'ı kullanılabilirlik testinde kullanmak: Katılımcıya durağan ekran gösterip "burada ne yapardınız" diye sormak, gerçek davranışı değil tahmini ölçer. Akışı ölçmek için en azından ekranları birbirine bağlayın.
• Cilalı prototiple erken test yapmak: Son hale çok yakın bir tasarım, katılımcıların eleştiri yapmaktan çekinmesine yol açabilir. Akışı sınarken görsel ayrıntıyı bilinçli olarak sade tutun.
• Yalnızca "mutlu yol"u prototiplemek: Kullanıcı hatalı veri girdiğinde ne olacağı tanımlanmamışsa test, gerçek kullanımın önemli bir kısmını kaçırır.
• Mockup'ı geliştirme şartnamesi sanmak: Durağan bir ekran, butonun basılı, pasif ya da yükleniyor halindeki görünümünü söylemez. Durumları ayrıca belgeleyin.
• Terimleri ekip içinde farklı anlamlarda kullanmak: Paydaş "prototip hazır mı" diye sorduğunda tıklanabilir bir dosya mı yoksa onaylı ekranlar mı beklediğini netleştirin.

Mindset UX/UI programlarında bu ayrımın yeri

UX / UI Uzmanlığı Sertifika Programı'nda wireframe ve düşük doğruluklu prototip ile yüksek doğruluklu prototip ve kullanılabilirlik testi ayrı modüller olarak yer alır; Figma ileri düzey kullanımı ve tasarım sistemi modülü de mockup üretiminin dayandığı bileşen düzenini ele alır.

UX/UI Bootcamp'te gerçek müşteri projesi tasarım, prototip ve test adımlarını içerir. Kullanıcı Araştırması (UX Research) eğitimindeki kullanılabilirlik testleri modülü ise prototiplerle yapılan testlerin nasıl planlanıp yorumlanacağına odaklanır.