Web Tasarımında Prototip: Hangi Soruyu Test Ettiğinizi Bilin
Prototipin işi güzel görünmek değil, bir soruyu ucuz yoldan cevaplamak. Menü yapısı mı tartışılıyor, yoksa butonun tonu mu? İkisine aynı prototiple bakılmaz ve projelerin çoğu zamanı tam burada kaybeder: yanlış soruya çok pahalı bir cevap hazırlanır.
Önce soruyu yaz, sonra aracı aç
Prototipe başlamadan önce bir cümle yazın: bu prototip neyi yanlışlarsa işe yaramış olacak? Cevap "kullanıcı kampanya sayfasından sepete gidemiyor" ise kutulardan ve oklardan ibaret bir çizim yeter. Cevap "ikinci adımdaki form insanları kaçırıyor" ise gerçek alanları, gerçek hata mesajlarını ve gerçek karakter sınırlarını taşıyan bir maket gerekir.
Bu cümleyi yazmayan ekipler ikisini birden yapar. Figma'da parlak bir ekran çıkar, müşteri onaylar, iki hafta sonra ödeme akışının üç adım olduğu ve mobilde kaydırma gerektirdiği fark edilir.
Tel kafes ve etkileşimli maket
| Özellik | Tel kafes | Etkileşimli maket |
|---|---|---|
| Cevapladığı soru | Yapı, akış, hiyerarşi | Görsel ağırlık, mikro etkileşim |
| Hazırlık süresi | Saatler | Günler, bazen haftalar |
| Atmanın maliyeti | Yok denecek kadar az | Yüksek, bu yüzden atılmıyor |
| Tipik araç | Balsamiq, kağıt, beyaz tahta | Figma, Adobe XD, Sketch |
Tablodaki üçüncü satır, çoğu rehberin atladığı satırdır.
Yüksek çözünürlüğün sessiz maliyeti
Bitmiş görünen bir ekranı test kullanıcısının önüne koyduğunuzda aldığınız geri bildirim de bitmiş görünen bir ekrana ait olur. İnsanlar renk, yazı tipi ve fotoğraf seçimi hakkında konuşur; "burada ne yapmam gerektiğini anlamadım" cümlesi kurulmaz, çünkü ekran anlaşılmayı hak edecek kadar profesyonel görünmektedir. Kaba bir çizim tam tersini yapar, izin verir.
İkinci maliyet ekibin kendi içindedir. Üç gün emek verilmiş bir maketi çöpe atmak, yarım saatte çizilmiş bir tel kafesi atmaktan zordur. Prototipin amacı fikri sınamaksa, sınavı geçemeyen fikri bırakabilmek gerekir; harcanan emek arttıkça o bırakma ihtimali düşer. Yatırımı düşük tutmak burada bir tasarruf değil, karar özgürlüğü.
"5 kullanıcı yeterli" gerçekte ne diyor
Jakob Nielsen'in yaygın olarak alıntılanan yazısı basit bir formüle dayanır: tek bir kullanıcı sorunların ortalama %31'ini bulursa, n kullanıcının yakaladığı oran 1 eksi 0,69 üzeri n olur. Beş kullanıcı için bu %84, on kullanıcı için %98 demektir.
Sayıya bu şekilde bakınca tavsiyenin mantığı görünür hale gelir. İkinci beş kişi, birinci beş kişiyle aynı parayı ve aynı takvimi tüketip yalnızca 14 puan ekler. Aynı bütçeyle iki ayrı turda beşer kişi test etmek, bir turda on kişi test etmekten çok daha fazla sorun yakalar, çünkü ilk turda bulunanlar düzeltilmeden ikinci tura girilmez.
Formülün sessizce varsaydığı şey ise şu: kullanıcılar aynı havuzdan geliyor. Sitenizde son müşteri ve bayi gibi iki farklı rol varsa, birinin takıldığı yerle diğerininki örtüşmez ve %31 varsayımı iki grubun toplamı için geçerliliğini yitirir. O durumda beş kişi grup başına beş kişidir, proje başına değil.
10 kat maliyet iddiasının kaynağı
"Geç bulunan hatayı düzeltmek 10 ila 100 kat pahalıdır" cümlesini prototipleme yazılarının yarısında görürsünüz, neredeyse hiçbirinde kaynağıyla birlikte değil. Rakam Barry Boehm'in 1981 tarihli Software Engineering Economics çalışmasından geliyor ve o çalışmadaki projeler şelale modeliyle yürüyen, aylık sürümler çıkaran büyük sistemlerdi.
Haftada iki kez sürüm alan bir web ekibi için aynı çarpanı savunmak zor. Yine de yönün doğru olduğunu söylemek için rakama ihtiyaç yok: canlıdaki bir formu değiştirmek, kağıttaki bir kutuyu silmekten her koşulda pahalıdır. Argümanı uydurma bir çarpanla süslemek onu güçlendirmez, sorulduğunda savunulamaz hale getirir.
Lorem ipsum yalan söyler
Yer tutucu metin, tasarımcının ayırdığı alana kusursuz sığar. Gerçek içerik sığmaz. Ürün adı 60 karakter, kategori başlığı iki satır, kullanıcının yazdığı adres üç satırdır ve hepsi tasarımın kabul ettiğinden uzundur.
Prototipe koyacağınız metinleri müşteriden isteyin. Elinde yoksa mevcut sitesinden en uzun beş başlığı ve en kısa üç açıklamayı kopyalayın. Uç değerlerle çalışan bir düzen ortalamayla da çalışır; tersi doğru değil.
Prototiplemeye değmeyen şeyler
Her ekranın prototipi çıkarılmaz. Gizlilik metni, iletişim sayfası, hakkımızda gibi tek sütunlu ve karar barındırmayan sayfalar için harcanan süre boşa gider. Zamanı, kullanıcının bir seçim yaptığı yerlere ayırın: filtreleme, sepet, kayıt formu, arama sonuçları.
Bir de şu var: prototip, geliştiriciye devredilirken bir belge işlevi görür. Animasyon süresi, alan formatı, hata durumundaki metin gibi ayrıntıları prototipin üstüne not düşmek, aynı soruları üç hafta sonra Slack'te cevaplamaktan hızlıdır.