Düşük Sadakatli Prototipler: Beş Yöntem ve Hangisinin Ne Zaman İşe Yaradığı
Bir prototipin sadakati, gerçek üründen ne kadar ayırt edilemez olduğudur. Düşük sadakatli prototip kasten ayırt edilir: kalem çizimi, kağıt parçası, gri kutulardan ibaret bir iskelet. Amaç güzel bir taslak üretmek değil, yanlış fikri hâlâ ucuzken elemek. Aşağıdaki beş yöntem bunu farklı maliyetlerle yapar ve birbirinden farklı sorulara cevap verir.
Sadakat tek bir ayar değildir
"Düşük sadakat" denince akla ilk gelen görüntü oluyor: çizgiler eğri, renk yok, font yok. Oysa sadakat en az üç ayrı eksende ölçülür. Görsel sadakat ürünün nasıl göründüğü, işlevsel sadakat gerçekten ne kadarının çalıştığı, içerik sadakati de ekrandaki metnin gerçek metin olup olmadığıdır.
Bu üçünün ayrı olduğunu görmek yöntem seçimini kolaylaştırıyor, çünkü bir prototip bir eksende dibe, başka bir eksende tavana oturabilir. Wizard of Oz tam olarak böyledir: görsel olarak kaba, işlevsel olarak tam. Kağıt prototip de öyle, arkasındaki insan sayesinde her etkileşime cevap verir. Prototip hazırlarken sorulacak doğru soru "ne kadar bitmiş görünsün" değil, "hangi eksende gerçekçi olmazsa cevap alamam" sorusudur.
1. Sketch: fikri masaya koymak
Serbest çizim, bir ekranın ya da akışın kabaca neye benzeyeceğini birkaç dakikada göstermenin en ucuz yolu. Çizim yeteneği gerekmiyor; kutular ve oklar yetiyor, bu yüzden toplantıdaki herkes katkı verebiliyor.
Sınırı ise şu: sketch kendi başına ayakta durmuyor. Çizen kişi yanında durup anlatmazsa kağıt üzerindeki kutular çoğu insana bir şey söylemiyor. Sketch'i bu yüzden bir iletişim aracı olarak görün, test aracı olarak değil. Beyin fırtınasında, akışın büyük resmini tartışırken, iki alternatifi yan yana koyup birini elerken işini yapar. Kullanıcının önüne tek başına konduğunda yapmaz.
2. Kağıt prototip: ellenebilen akış
Her ekranı ayrı bir kağıda çizersiniz, kullanıcı parmağıyla bir yere dokunur, siz o kağıdı çekip bir sonrakini koyarsınız. Akışın gerçekten tıkanıp tıkanmadığını en erken bu yöntem söylüyor.
İlk turda kağıdı dijital wireframe'den daha güvenilir bulurum. Ekranda düzgün hizalanmış gri kutular gören kullanıcı, karşısındakinin üzerinde epey emek olduğunu varsayıp eleştirisini yumuşatıyor; elinde buruşuk bir kağıt tutan kişi ise "burası saçma olmuş" demekte zorlanmıyor. Bitmemiş görünmek bir kusur değil, kağıt prototipin asıl işlevi.
Karşılığında bir şey kaybediyorsunuz: uzaktan test edemiyorsunuz. Kullanıcıyla aynı odada olmanız gerekiyor, bu da katılımcı sayısını doğal olarak düşürüyor. Teste geçmeden önce ekipten biriyle bir prova yapın, çünkü hangi dokunuşun hangi kağıda gittiğini karıştırmak testin ritmini bozan en sık hata.
3. Lego: fiziksel ürünün ölçeği
Fiziksel bir ürün tasarlıyorsanız, çizim bir şeyi hiç anlatmıyor: büyüklük. Bir cihazın masada ne kadar yer kapladığını, elde nasıl durduğunu ancak üç boyutlu bir şey tutunca anlıyorsunuz. Lego bunu ölçekli ve hızlıca yapmanızı sağlıyor.
Bu yöntem çoğu kaynakta "düşük maliyet" başlığı altında geçer, ki bu doğru değil. Bir lego seti kalem ve kağıttan pahalıdır, üstelik parça çeşidi yetmezse ikinci kutuyu almak gerekir. Lego'yu bu listede tutan şey fiyatı değil, sökülebilirliği: bir parçayı değiştirmek için modelin geri kalanını bozmuyorsunuz, on saniyede farklı bir varyantla test edebiliyorsunuz. Düşük sadakatin asıl vaadi zaten ucuzluk değil, ucuz vazgeçebilmek.
4. Wireframe: iskelet ve içerik yerleşimi
Wireframe, bir ekranın hangi bloklardan oluştuğunu ve bu blokların hiyerarşisini gösterir. Balsamiq gibi araçlar bunu bilerek kaba çizdirir; renk, font ve görsel tartışmasını masadan kaldırıp konuyu yapıya sabitlemek için.
Buradaki klasik hata lorem ipsum. Sorun estetik değil, ölçü. Yer tutucu metin hep aynı ritimde ve aynı uzunlukta akar, oysa gerçek içerik akmaz: ürün adlarının biri iki kelime, öteki yedi kelimedir, bir açıklama boş kalır, bir başlık üç satıra taşar. Türkçe metnin İngilizce karşılığından belirgin biçimde uzaması da düzeni ayrıca zorlar. Yer tutucuyla verdiğiniz yerleşim kararı, gerçek içerik gelince bozulur. Her alan için elinizdeki en kısa ve en uzun gerçek örneği koyun; wireframe'in asıl sınavı ortalama içerik değil, uçlar.
5. Wizard of Oz: olmayan sistemi oynamak
Kullanıcı gerçek bir ürünle konuştuğunu sanır, arka planda cevapları bir ekip üyesi verir. Sesli asistan, öneri motoru, otomatik sınıflandırma gibi yazılması pahalı olan her şeyde tek satır kod yazmadan davranış testi yapmanızı sağlar.
Bir sınırı var ve genelde atlanıyor: perdenin arkasındaki operatör insan. İnsan operatör kullanıcının yazım hatasını anlar, yarım kalmış cümlesini tamamlar, imayı yakalar. Gerçek sistem bunların hiçbirini bedavaya yapmaz. Ayrıca cevap gecikmesi insan hızındadır, gerçek sistemde başka türlü olacaktır. Yani Oz testi "insanlar böyle bir şeyi kullanmak ister mi" sorusunu iyi cevaplar, "sistem bunu becerebilir mi" sorusunu hiç cevaplamaz. İkincisini teknik bir fizibiliteyle ayrıca yanıtlamak gerekiyor, aksi halde testten çıkan olumlu sonuç sizi karşılığı olmayan bir söze bağlar.
Senaryoyu ve operatörün nasıl davranacağını önceden yazın. Yazmazsanız her katılımcı farklı bir ürünle karşılaşır ve sonuçları karşılaştıramazsınız.
Sırayı nasıl kurmalı
Yöntemleri bir merdiven gibi düşünmek yanıltıcı, çünkü hepsi aynı soruyu farklı çözünürlükte sormuyor. Sketch ekip içinde fikir ayıklarken, kağıt ilk kullanıcı testinde, wireframe içerik ve yerleşim tartışmaya açıldığında, Wizard of Oz ise belirsizlik teknik değil davranışsal olduğunda işe yarıyor. Lego yalnızca ortada fiziksel bir nesne varsa listeye giriyor.
Bir aşamadan diğerine geçme ölçütü de takvim değil: eldeki prototip yeni bir şey söylemeyi bıraktığında geçin. Arka arkaya iki kullanıcı aynı yerde takılıyor ve siz zaten bunu biliyorsanız, o prototip işini bitirmiştir. Tersi de geçerli, her katılımcı başka bir yerde tökezliyorsa henüz bir üst sadakate çıkmanın zamanı gelmemiştir.
Kaynaklar