Prototipleme: Ne Zaman Kağıt, Ne Zaman Tıklanabilir Prototip

Prototip, fikrin kendisini değil, fikir hakkındaki bir soruyu sınamak için vardır. Soru netleşmediğinde prototip hızla amaçsız bir maket çalışmasına dönüşür; "kağıt mı olsun, tıklanabilir mi olsun" tartışması da çoğu zaman bu yüzden yanlış tartışmadır. Tutarlılık seviyesi bir tercih değil, cevabını aradığınız sorunun sonucudur.

Prototip hangi soruyu cevaplıyor?

Başlamadan önce sorulacak şey "ne yapalım" değil, "neyi bilmiyoruz". Akışın anlaşılıp anlaşılmadığını mı merak ediyorsunuz, yoksa bir etkileşimin parmak altında nasıl hissettirdiğini mi? Bu iki soru farklı prototip ister ve birbirinin yerine geçmez.

Odak sorusu yazılmamış bir prototip test edilemez, yalnızca beğenilir ya da beğenilmez. Toplantı da doğal olarak renk ve yazı tipi tartışmasına kayar, çünkü herkesin fikir söyleyebileceği tek katman odur.

Düşük tutarlılık, ucuz olduğu için değil atılabilir olduğu için işe yarar

Kağıt prototipin, storyboard'un asıl faydası maliyet kalemi değil. Yarım saatte çizilen bir akışı çöpe atmak kimseyi incitmez, bu yüzden gerçekten değiştirilir. İkinci versiyon aynı gün çıkar.

Peki kağıtla göremediğiniz ne var? Kaydırma davranışı, bekleme süresi, mobilde klavye açılınca ekranın yarısının kaybolması. Bunlar kağıtta yokmuş gibi durur, oysa canlıda kullanıcıyı en çok zorlayan tam bu üçü olabilir.

Card sorting bir prototip değil

Prototipleme anlatılırken card sorting sık sık düşük tutarlılıklı teknikler arasına konur, ama oraya ait değil. Card sorting bir tasarımı sınamaz; kullanıcıların içerikleri nasıl grupladığını öğrenir. Ortada denenecek bir öneri yoktur, girdi toplanır.

Sırayı karıştırınca ne olur: kimsenin henüz önermediği bir menü yapısını "doğruladığınızı" sanırsınız. Card sorting bilgi mimarisini kurmadan önce yapılır, kurulan mimarinin testi ise ağaç testi ya da görevli bir kullanım testidir.

Yüksek tutarlılık ve dikkatin kayması

Figma, Sketch veya Adobe XD ile hazırlanan tıklanabilir prototipler gerçek ürüne yaklaştıkça geri bildirimin cinsi de değişir. Bitmiş görünen bir ekranda insan bitmemiş bir şey arar mı? Genelde aramaz; "burası biraz sıkışık olmuş" der ve akışın kendisi tartışılmadan geçilir.

Üzerine emek harcanan prototipe direnç göstermek ekip inadı değil, harcanan emeğin doğal sonucu. Yüksek tutarlılığı bu yüzden akış oturduktan sonraya bırakmak daha iyi çalışıyor: değiştirilecek şey azalınca cilanın bedeli de düşüyor.

Prototiple çalışan ürün arasındaki mesafe

Prototipte kural olarak tek bir yol vardır: doğru veri, dolu liste, başarılı istek. Kodda ise aynı ekranın taşıması gereken durumlar çoğalır:

• boş durum (hiç kayıt yokken)
• yükleniyor ve zaman aşımı
• sunucu hatası ve doğrulama hatası
• yetkisi olmayan kullanıcı
• yarım kalmış, geri dönülen form

Bir ekranın süresini tahmin ederken prototipteki tıklama yolunu esas almam; kaç durumun hiç çizilmediğine bakarım. Beş ekranlık şık bir akış, çizilmemiş yirmi durumla birlikte gelir ve fark genellikle oradan çıkar.

Bu, yüksek tutarlılıklı prototipi gereksiz kılmıyor. Yalnızca şunu söylüyor: prototip görsel bir anlaşma metnidir, mühendislik tahmini değildir. İkisini aynı belge saymak, süre tartışmasını sonraya erteler.