Hızlı Prototipleme: Doğru Soruyu Ucuza Sormak

Prototip, ürünün küçültülmüş hali değil, bir sorunun ucuz cevabıdır. Hangi soruyu sorduğunu bilmeden çizilen prototip ekibe cevap getirmez, yeni bir tartışma konusu getirir. Hızlı prototipleme dediğimiz şeyin tamamı bu ayrımın üstünde duruyor: önce soruyu netleştir, sonra o soruya yetecek kadar sadakatte bir şey yap.

Her prototip tek bir soruya çalışır

Bir prototipi masaya koyduğunuzda ekipteki herkes farklı bir şeye bakar. Yazılımcı veri modelini, tasarımcı hizalamayı, satıştan gelen arkadaş fiyat etiketini görür. Bu dağınıklığın sebebi ekibin dikkatsizliği değil, prototipin ne için yapıldığının yazılı olmaması.

Çizime başlamadan önce tek cümlelik bir soru yazın. "Kullanıcı üç adımlı kaydı yarıda bırakmadan tamamlıyor mu?" bir sorudur. "Tasarım nasıl olmuş?" soru değil, anket. İlkinde testten sonra elinizde bir sayı ya da net bir gözlem kalır; ikincisinde herkesin zevki kalır.

Soruyu yazmanın ikinci faydası, testi ne zaman bitireceğinizi bilmenizdir. Cevap geldiyse o prototibin işi bitmiştir, cilalamaya devam etmenin getirisi yoktur.

Sadakat seviyesi, sorunun boyuna göre seçilir

Sadakat (fidelity), prototipin gerçek ürüne ne kadar benzediğidir. Yüksek sadakat daha iyi değil, sadece daha pahalıdır. Hangisini seçeceğiniz elinizdeki soruya bağlı:

• Eskiz: kağıt, kalem, on dakika. Akışın mantıklı olup olmadığını, adım sırasının doğru olup olmadığını gösterir.
• Wireframe: yerleşim ve hiyerarşi soruları için. Renk ve tipografi bilinçli olarak dışarıda tutulur, çünkü onlar başka bir sorunun konusu.
• Yüksek detaylı maket: gerçek metin, gerçek uzunlukta veri, çalışan etkileşim. Mikro etkileşimleri ve gerçek içerikle bozulan yerleşimi ancak burada görürsünüz.

Yüksek detaylı prototipin bilinen bir tuzağı var: bitmiş göründüğü için insanlar konsepti tartışmayı bırakır, buton köşelerini tartışmaya başlar. Kullanıcı testinde de aynısı olur, katılımcı yarım kalmış bir şeyi eleştirmekten çekinmezken cilalı bir şeyi kırmak istemez.

Bir de kod tarafı var. Yüksek detaylı prototipin kodunu ürüne taşımam. O kod, sorunun cevabını en hızlı almak için yazılmıştır; hata durumu, yetkilendirme, veri doğrulama, hepsi kasten yoktur. Prototipi ürüne terfi ettirdiğinizde bu eksikleri devralırsınız ve hangi kısmın gerçekten düşünülmüş, hangisinin geçici olduğunu altı ay sonra kimse hatırlamaz.

Olana kadar olmuş gibi yapmak

Wizard of Oz yöntemi, kullanıcıya otomatik görünen bir sistemin arkasında bir insanın oturmasıdır. Kullanıcı formu doldurur, arkada biri manuel olarak cevabı hazırlar, kullanıcı sistemin çalıştığını sanır. Aardvark bunu yıllarca yaptı: soru-cevap eşleştirmesini otomatik yapıyormuş gibi görünen sistemin ardında operatörler vardı ve ürün tam otomatik hale gelmeden önce iş modelinin tuttuğu böyle kanıtlandı.

Yöntemin değeri şurada: kod yazmadan gerçek talebi ölçersiniz. İnsanlar anket cevaplarken ne isteyeceklerini bilmezler, ama bir şeyi kullanmaya ne kadar emek harcadıkları ölçülebilir bir veridir.

Sınırı da açık. Manuel iş, kullanıcı sayısıyla doğru orantılı büyür. Her talebe beş dakika harcıyorsanız günde yüz talep, tek başına sekiz saatten fazla insan mesaisi demektir. Yani Wizard of Oz'un bir son kullanma tarihi vardır ve bu tarih, ürün tuttuğu anda gelir. Doğrulama aracı olarak mükemmel, iş modeli olarak sürdürülemez. Bu yüzden yöntemi başlatırken "kaç kullanıcıya kadar dayanır" sorusunun cevabını da hesaplayın, tıkandığınız gün panikle otomasyon yazmak zorunda kalmayın.

PR2I: döngüyü ayakta tutan şey

Ekta Srivistava'nın önerdiği PR2I döngüsü dört adımdan oluşur: prototipleme, gözden geçirme, iyileştirme, yineleme. Adımların kendisi sürpriz değil, asıl mesele döngünün kapanması.

Prototipleme aşamasında elinizde bir soru ve o soruya yetecek en ucuz malzeme olur. Gözden geçirmede prototip paydaşlarla ve mümkünse gerçek kullanıcılarla karşılaşır; burada toplanan geri bildirimi kime ait olduğunu not ederek yazın, çünkü "ekip beğenmedi" ile "beş kullanıcıdan dördü aynı yerde takıldı" aynı ağırlıkta değil. İyileştirme aşamasında geri bildirimin hepsini değil, sorunuza dokunan kısmını uygularsınız. Yineleme ise bir sonraki soruyla başlar.

Döngü çoğu ekipte gözden geçirmeden sonra kırılıyor. Geri bildirim toplanıyor, bir dosyaya yazılıyor, sonra sprint planlamasında kayboluyor. Bunun pratik çaresi, her turun sonunda tek bir karar cümlesi yazmak: neyi değiştiriyoruz, neyi kasten değiştirmiyoruz.

Prototipi ne zaman bırakmalı

Prototipin işi fikrinizi değiştirmektir. Son iki turda hiçbir şey sizi şaşırtmadıysa, o prototip artık bilgi üretmiyor demektir; ondan sonra harcadığınız her saat, cevabını zaten bildiğiniz bir soruyu daha güzel sormaya gidiyor.

Sketch, Figma, Balsamiq gibi araçlar bu döngüyü hızlandırır ama seçimi sizin yerinize yapmaz. Asıl tasarruf araçtan değil, doğru soruyu ucuz malzemeyle sormaktan geliyor. Kağıt üzerinde on dakikada anlaşılan bir akış hatası, üç hafta sonra kodda bulunduğunda çok daha pahalıya patlar.