Wireframe, Mockup ve Prototip Farkı

Ürün ekiplerinde "tasarımı gördük" cümlesi çoğu zaman belirsizdir. Bir yönetici renkli bir ekran görüntüsünü onaylamıştır, geliştirici aynı ekranın tıklanabilir sürümünü bekliyordur, tasarımcı ise hâlâ yapıyı tartışmak istiyordur. Wireframe, mockup ve prototip arasındaki farkı netleştirmek, hangi aşamada hangi geri bildirimi istediğinizi de netleştirir. Bu yazı üç kavramı tanımlıyor, doğruluk seviyelerini açıklıyor ve prototiplerin nasıl test edileceğini anlatıyor.

Üç kavramın tanımı

NN/g'nin UX çıktıları sözlüğü üç terimi şöyle ayırır 1:

• Wireframe (tel kafes): Görsel tasarım düşünülmeden önce bir arayüzün yapısını ve işlevini temsil eden iskelet düzen.
• Mockup: Renk ve görsel gibi görsel tasarım ayrıntılarını içeren, önerilen arayüzün durağan ve yüksek doğruluklu bir canlandırması.
• Prototip: Fikirleri, etkileşimleri ve işlevselliği test etmek ve doğrulamak için kullanılan erken bir tasarım sürümü.

ISO 9241-210 standardı prototipi daha geniş tanımlar: etkileşimli bir sistemin tamamının ya da bir bölümünün, bir şekilde sınırlı olsa da analiz, tasarım ve değerlendirme için kullanılabilen temsili. Standardın notuna göre bir prototip bir eskiz ya da durağan bir mockup kadar basit, ya da neredeyse tam işlevli bir sistem kadar karmaşık olabilir 2. Bu tanım önemli bir noktayı vurgular: prototipi prototip yapan görünüşü değil, değerlendirme için kullanılmasıdır.

Karşılaştırma tablosu

Bu üçlüye sık karıştırılan bir dördüncü çıktı eklenebilir: wireflow. Wireflow, tel kafes düzeyindeki ekranları akış şemasına benzer bir etkileşim gösterimiyle birleştirir ve özellikle içeriği dinamik değişen mobil uygulama ekranlarını belgelemek için uygundur 7. Akışın kendisini nasıl çizeceğinizi kullanıcı akışı nasıl çizilir yazısında anlattık.

Doğruluk tek bir ölçek değildir

"Düşük doğruluklu" ve "yüksek doğruluklu" ifadeleri genellikle görünüşü anlatmak için kullanılır. NN/g ise prototip doğruluğunu üç ayrı boyutta ele alır 3:

1. Etkileşim: Tıklanabilir öğeler kendiliğinden mi çalışıyor, yoksa bir kişi mi kullanıcının eylemine yanıt veriyor?
2. Görsel: Grafikler, boşluklar ve düzen son sisteme ne kadar benziyor?
3. İçerik ve gezinme: Gerçek içerik mi kullanılıyor, yoksa özetler ve yer tutucular mı?

Bu ayrım pratik bir karar aracıdır. Örneğin bir bankacılık uygulamasında para transferi akışını test ediyorsanız görsel doğruluğu düşük tutup içerik doğruluğunu yüksek tutmak mantıklıdır: alıcı adı, IBAN alanı, tutar ve "Gönder" adımındaki metinler gerçeğe yakın olmalıdır, ama renk paleti henüz kesinleşmemiş olabilir. Tersine, bir ana ekranın görsel hiyerarşisini sınıyorsanız görsel doğruluk öne çıkar.

NN/g'ye göre düşük doğruluklu prototipler daha hızlı hazırlanır, test sırasında bile kolayca değiştirilebilir ve tasarımcıların bu taslaklara daha az bağlanmasını sağlar; paydaşlar da işin bitmediğini açıkça görür 3. Yüksek doğruluklu prototiplerde ise kullanıcılar gerçek bir sistemle etkileşimdeymiş gibi daha gerçekçi davranır; taslak bir prototipte neyin çalışması gerektiğine dair beklentileri belirsiz kalabilir 3. Aynı yazı, çok cilalı görünen bir tasarımın yöneticileri "bu iyi görünüyor, hemen yayına alalım" tuzağına düşürebileceği konusunda da uyarır 3.

Hangi aşamada hangisi kullanılır?

1. Keşif ve fikir aşaması: Kâğıt ya da beyaz tahtada hızlı tel kafesler. Birden çok yaklaşımı yan yana koyup tartışmak için. NN/g, çizim becerisinin ön koşul olmadığını, birkaç ortak kural öğrenen herkesin tel kafes çizebileceğini belirtir: kalın kalem kullanmak, süre sınırı koymak, görseller için çarpı işaretli kutular çizmek gibi 5.
2. Akış doğrulama: Düşük doğruluklu tıklanabilir prototip ya da kâğıt prototip. Soru "kullanıcı görevi tamamlayabiliyor mu?" olduğunda.
3. Görsel yönün belirlenmesi: Seçili birkaç ekranın mockup'ları. Soru "ürün nasıl görünmeli?" olduğunda.
4. Ayrıntılı doğrulama: Yüksek doğruluklu prototip. Gerçek içerik, gerçekçi geçişler ve mümkünse kullanıcının kendi telefonunda.
5. Geliştirici devri: Tüm durumları (boş, yükleniyor, hata, devre dışı) içeren tasarım dosyası ve gerekirse etkileşimleri gösteren prototip.

GOV.UK Service Manual, alfa aşamasını prototip yapıp farklı fikirleri denemek için kullanmayı önerir ve bu aşamada yalnız fikirleri test etmeye yetecek kadar karmaşık şeyler yapılmasını, kodun ve test edilen fikirlerin çoğunun aşama sonunda atılmasının beklenmesi gerektiğini belirtir 8. Aynı kaynak eskizlerin ekip içi ilk tartışmalar için, gerçeğe yakın davranan prototiplerin ise kullanıcı testleri için daha uygun olduğunu söyler 6.

Kâğıt prototip neden hâlâ işe yarar?

Kâğıt prototipte her ekran ayrı bir kâğıda çizilir. Katılımcı parmağıyla bir düğmeye "dokunur", ekipten bir kişi bilgisayar rolünü üstlenip bir sonraki kâğıdı önüne koyar. NN/g bu yöntemi kâğıt prototip "bilgisayarı" olarak tanımlar; benzer bir yaklaşım olan Oz Büyücüsü (Wizard of Oz) yönteminde ise tasarımı bilen bir kişi kullanıcının ekranını başka bir odadan uzaktan yönetir 3.

Jakob Nielsen'in kâğıt prototip üzerine yazısının ana fikri, erken test etmenin prototip kalitesindeki farklardan çok daha önemli olduğudur; beklerseniz kullanılabilirlik bulgularını tasarımın yönüne yansıtmak için geç kalabilirsiniz 4. Kâğıt prototipin sınırları da vardır: bilgisayar rolündeki kişinin geç yanıt vermesi kullanıcının akışını bozabilir 3, kaydırma, hareket ve klavye davranışı gibi ayrıntılar kâğıtta test edilemez.

Mobil uygulamalar için kâğıt prototipin bir avantajı daha vardır: telefon boyutunda kartlar kullanıldığında ekranın sınırlı alanı ve neyin ilk ekrana sığmadığı hemen görünür.

Prototipleri nasıl test edersiniz?

NN/g'nin önerisi açıktır: tıklanabilir ya da durağan, düşük ya da yüksek doğruluklu olsun, prototipleri test edin 3. Kısa bir prototip testi şu adımlarla kurulabilir:

• Görev yazın, talimat değil. "Profil sekmesine gidip adres ekleyin" yerine "Siparişinizin yeni evinize gelmesini istiyorsunuz" gibi bir senaryo verin.
• Prototipin sınırlarını baştan söyleyin. Katılımcıya bazı bölümlerin çalışmayabileceğini, bunun onun hatası olmadığını belirtin.
• Gözlemleyin, açıklamayın. Katılımcı takıldığında hemen yardım etmek yerine ne düşündüğünü sesli anlatmasını isteyin.
• Kısa turlar yapın. Bir turda bulunan büyük sorunları düzeltip yeni bir turda tekrar deneyin.

Test sürecinin ayrıntıları için kullanılabilirlik testi nasıl yapılır, katılımcı sayısı için kaç kullanıcıyla test yapılmalı yazılarına bakabilirsiniz.

Mobil uygulama prototiplerinde dikkat edilecekler

Mobil ürünlerde prototipin masaüstü ekranında gösterilmesi, test sonuçlarını önemli ölçüde değiştirebilir. Fare ile tıklamak, başparmakla dokunmaktan farklıdır; ekranın alt köşesindeki bir düğme masaüstünde kolay görünür ama tek elle kullanımda zor olabilir. Bu yüzden yüksek doğruluklu mobil prototipler mümkün olduğunca katılımcının kendi telefonunda ya da en azından gerçek bir cihazda denenmelidir.

Prototipe şu durumları da eklemeyi düşünün:

• Klavye açıkken ekran: Form alanına dokunulduğunda klavye ekranın yarısını kaplar; "Devam" düğmesi görünür kalıyor mu?
• Sistem izin pencereleri: Konum, bildirim ya da kamera izni hangi anda isteniyor ve kullanıcı reddederse akış nasıl devam ediyor?
• Kesintiler: Kullanıcı SMS kodunu okumak için uygulamadan çıkıp geri döndüğünde girdiği bilgiler korunuyor mu?
• Uzun metin ve büyük yazı boyutu: Türkçe metinler İngilizce karşılıklarından uzun olabilir; sistemde büyük yazı boyutu seçili olduğunda düğme metinleri taşıyor mu?

Bu durumların hepsini prototipte tıklanabilir yapmak gerekmez. Bazen tek bir durağan ekranla "bu noktada klavye açılıyor" demek, sorunu ekibin gözü önüne getirmeye yeter.

Sık yapılan hatalar

• Mockup'ı onaylanmış ürün sanmak: Durağan bir ekranın onaylanması, akışın çalıştığı anlamına gelmez.
• Tel kafesi gereğinden fazla cilalamak: Tel kafes ne kadar bitmiş görünürse, yapıya dair eleştiri o kadar azalır.
• Yer tutucu metin kullanmak: Gerçek metin olmadan "Bu düğme ne yapar?" sorusu test edilemez; Türkçe metinlerin uzunluğu da düzeni değiştirir.
• Prototipi yalnız mutlu yolla sınırlamak: Hatalı giriş, boş liste ve bağlantı kopması durumları test edilmezse en sık sorun çıkan yerler görünmez kalır.
• Prototip kodunu ürüne taşımak: GOV.UK, prototip kodunun canlı kodla aynı standartları karşılamak zorunda olmadığını ve doğrudan canlıya kopyalanmaması gerektiğini vurgular 6.

Tel kafesten geliştirici devrine kadar adımların nasıl ilerlediğini ürün tasarım süreci sayfasında, mobil uygulamalar için kapsamı ise mobil uygulama tasarımı hizmet sayfasında bulabilirsiniz.