Prototip Testi Rehberi: Kod Yazmadan Çözümü Doğrulamak
Prototip testi, çözüm hipotezinin en ucuz sınavıdır: gerçek ürün yerine tıklanabilir taslak (Figma), kâğıt eskiz veya sahte kapı ile kullanıcının çözümle etkileşimini gözlemlersiniz. Mülakat problemin varlığını, landing page talebi kanıtlar; prototip ise "önerdiğimiz çözüm, kullanıcının zihninde çalışıyor mu?" sorusunu cevaplar.
Sadakat Düzeyi: Ne Kadar Gerçekçi Olmalı?
Prototipin gerçekçilik düzeyi, test edilen soruya göre seçilir daha cilalı her zaman daha iyi değildir:
| Düzey | Araç | Neyi test eder |
|---|---|---|
| Kâğıt/eskiz | Çizim, tahta | Kavram ve akış mantığı "bu adımlar mantıklı mı?" |
| Düşük sadakat tıklanabilir | Figma tel çerçeve | Bilgi mimarisi, görev akışı "kullanıcı yolu buluyor mu?" |
| Yüksek sadakat tıklanabilir | Figma final tasarım | Anlaşılırlık, değer algısı, mikro kararlar |
| Sihirbaz prototipi (Wizard of Oz) | Önyüz gerçek, arka plan insan | Değer teklifi uçtan uca otomasyon yokken hizmeti elle vermek |
| Sahte kapı (fake door) | Var gibi görünen özellik düğmesi | Özellik talebi kim tıklıyor, ne kadar? |
Erken aşama kuralı: kavram belirsizken düşük sadakat (kullanıcı esere değil fikre odaklanır, eleştirmekten çekinmez); mesaj ve değer algısı test edilirken yüksek sadakat. Cilalı prototipin tuzağı, kullanıcının tasarımı beğenmesiyle çözümü onaylamasının karışmasıdır.
Test Senaryosu: Görev Verin, Tur Atmayın
Prototip testinin en yaygın hatası "ürün turu" yapmaktır: siz anlatırsınız, kullanıcı kibarca onaylar. Doğru kurgu görev bazlıdır:
- Bağlam verin, yönlendirmeyin: "Haftalık vardiya planını bu araçla yapmanız gerekiyor. Nereden başlarsınız?" "şu menüye tıklayın" değil
- Sesli düşünmeyi isteyin: "Ne düşündüğünüzü, ne beklediğinizi söyleyerek ilerleyin"
- Sessiz kalın: Kullanıcı takıldığında yardım etme dürtüsü, testin en değerli verisini (takılma noktası) siler. 10 saniye sessizlik kuralı: yardım etmeden önce bekleyin
- Davranışı not edin, beyanı değil: "Çok kullanışlı" beyanı değersiz; "3. adımda geri döndü, fiyat sayfasını aradı" gözlemi değerlidir
- Kapanışta değer sorusu: "Bu, bugünkü yönteminizin yerini alır mıydı? Neden?" buradaki tereddüt, tüm övgülerden bilgilendiricidir
5-7 kullanıcı, büyük kullanılabilirlik sorunlarının çoğunu yakalar; aynı segmentten olmaları şartıyla. İki turlu yapı idealdir: 5 test → düzeltme → 5 test.
Sihirbaz Prototipi: Otomasyonsuz Uçtan Uca Test
Yazılımın aylar sürecek kısmını insanla ikame etmek kullanıcı önyüzü gerçek sanır, arkada işi siz elle yaparsınız çözüm doğrulamanın en güçlü ara basamağıdır: "kişiye özel haftalık öğün planı algoritması" yerine ilk 20 müşterinin planını diyetisyen elle hazırlar. Ölçtüğü şey prototipten fazladır: gerçek kullanım, gerçek tekrar davranışı, hatta gerçek ödeme. Kritik disiplin: birim maliyeti ve sürdürülemezliği baştan kabul edin amaç ölçek değil, "otomatikleştirmeye değer mi?" sorusunun cevabıdır.
Bulgular Karara Nasıl Döner?
Prototip testinin çıktısı üç kovaya ayrılır: kavram sorunları (kullanıcı çözümün ne işe yaradığını anlamıyor → değer önerisi/kurgu revizyonu; en ağır sinyal), akış sorunları (anlıyor ama yolu bulamıyor → tasarım düzeltmesi; normal ve ucuz) ve değer boşlukları ("anladım ama bugünkü yöntemimden iyi değil" → çözüm hipotezi zayıf; özellik eklemeden önce farklılaşmayı yeniden düşünün). İlk kovadaki sorunlar tasarım cilasıyla çözülmez bu ayrımı yapmamak, kavram sorununu iki ay arayüz parlatarak çözmeye çalışmakla sonuçlanır.
Sık Sorulan Sorular
Prototip testi ile MVP arasındaki fark ne; hangisi önce?
Prototip "çözüm anlaşılıyor ve isteniyor mu?"yu simülasyonla, MVP "gerçekten kullanılıyor mu?"yu gerçek kullanımla test eder. Sıra her zaman prototip → MVP'dir: prototipte çökecek kavramı MVP'de keşfetmek, haftalar yerine aylar kaybettirir. Prototipten MVP'ye geçiş sinyalleri: kullanıcılar görevleri yardımsız tamamlıyor, "bugün kullanabilir miyim?" sorusu kendiliğinden geliyor ve değer sorusuna tereddütsüz olumlu cevap alınıyor.
Kullanıcılar prototipte her şeyi beğeniyor; gerçek sinyali nasıl ayırt ederim?
Beğeni beyanını değil davranış sinyallerini okuyun: görevi tamamlama süresi ve hatası, istenmeden sorulan sorular ("bunu telefondan da yapabilir miyim?" gerçek ilgi işareti), ve bedel testleri. En güçlüsü test sonuna mikro-taahhüt eklemektir: "Çıkınca beta listesine ekleyeyim mi? Pilot için takviminizden 1 saat ayırır mısınız? Ekibinizden kim katılmalı?" evet diyenlerin oranı, "harika olmuş" diyenlerin oranından çok daha dürüst bir metriktir.
B2B ürününde prototipi kime test ettirmeliyim; karar verici mi son kullanıcı mı?
İkisine de, ama farklı senaryolarla: son kullanıcıya görev bazlı kullanılabilirlik testi (günlük akış çalışıyor mu?), karar vericiye değer yürüyüşü (problem-çözüm-sonuç kurgusu + "bütçe ayırır mıydınız?" kapanışı). Sık hata, tüm testleri meraklı ama yetkisiz kullanıcılarla yapmaktır: ürün sevilir, satış gelmez. Test planınızda ikisini ayrı kotalayın: 5 son kullanıcı + 3 karar verici, tek profilden 8 kişiden iyidir.
Figma bilmiyorum; prototip için tasarımcı mı işe almalıyım?
Gerekmez erken aşama prototipinin amacı güzellik değil öğrenmedir: hazır UI kit'lerle temel Figma birkaç günde öğrenilir, hatta slayt aracıyla (tıklanabilir bağlantılı) bile ilk tur yapılabilir. Sahte kapı testi için tek ekran yeter. Tasarımcı yatırımı, kavram doğrulandıktan sonra (yüksek sadakat + marka aşamasında) anlamlıdır. Araç yüzünden testi ertelemek, en pahalı prototipin (yazılmış yanlış ürün) yolunu açar.