İteratif Tasarım: Döngü Neyi Düzeltir, Neyi Gözden Kaçırır
İteratif tasarım basit bir döngüdür: yap, test et, düzelt, baştan başla. Yaygın anlatım bu döngüyü tek başına bir kalite garantisi gibi sunar. Değildir. Döngü, neyi düzeltebildiğini ve neyi hiç göremediğini bilerek kurulduğunda işe yarar.
Döngünün gerçekten yaptığı iş
Prototipi çıkarırsın, kullanıcıya verirsin, izlersin, gördüğünle prototipi değiştirirsin. Dört adım, sonra başa dön. Buradaki değer tahminleri erken kesmesindedir: bir ekran akışının tutmadığını altı kişiyi izleyerek üç günde öğrenirsin, aynı bilgiyi canlıdaki hata kayıtlarından toplaman aylar alır.
Klasik anlatım burada biter. Asıl mesele döngünün nerede tıkandığı.
İterasyon bir tepe tırmanışıdır
Her turda eldeki tasarımın biraz daha iyisine geçersin. Bu, arama algoritmalarındaki tepe tırmanışının (hill climbing) aynısıdır: bulunduğun noktadan çevrene bakar, en dik yukarı yönü seçersin. Yöntem seni üzerinde durduğun tepenin zirvesine çıkarır. Yandaki daha yüksek tepeyi göstermez, çünkü oraya bakmıyorsundur.
Pratikteki karşılığı net: kötü kurgulanmış bir kayıt formu her turda biraz daha iyi olur. Alan sayısı düşer, hata mesajları anlaşılır hale gelir, tamamlanma oranı yükselir. Formun tamamen gereksiz olduğunu, istenen verinin zaten sistemde durduğunu hiçbir tur söylemez. Çünkü her turda sorulan soru aynıdır: bu form nasıl daha iyi olur.
Çare, döngüye belirli aralıklarla farklı bir soru sokmaktır. Üç turda bir, ekranı iyileştirmeyi bırakıp o ekranın hiç olmadığı bir akış çiz. Kullanıcıya iki akışı da göster. Bu tek hamle, iterasyonun yapısal körlüğünü kapatan tek şeydir.
Her turun sabit bir maliyeti var
"Ne kadar çok iterasyon, o kadar iyi" cümlesi tur maliyetini sıfır varsayar. Katılımcı bulmak, randevulaşmak, oturumu kaydetmek, notları ayıklamak, ekibi toplayıp kararı almak: tasarımın kendisiyle ilgisi olmayan, her turda baştan ödenen bir yük.
Diyelim bu yük tur başına iki gün. Altı turluk bir plan, on iki günü tasarımı değiştirmeye değil döngüyü çalıştırmaya harcar. Aynı bütçeyi üç iyi hazırlanmış tura bölmek çoğu projede daha fazla bilgi üretir, çünkü tur sayısı azaldıkça her turda sorulacak sorunun ne olduğu üzerinde gerçekten düşünülür. Tur sayısı bir başarı göstergesi değil, bir bütçe kalemidir.
Erken turlarda kaba çizim, cilalı prototipten daha iyidir
Kâğıda çizilmiş bir akışı, kodlanmış ve tasarım sistemine oturtulmuş bir ekrandan daha güvenilir bulurum. Sebebi katılımcının psikolojisi: kaba çizim bitmemiş görünür, insan bitmemiş bir şeye rahatça itiraz eder. Cilalı ekran karara bağlanmış görünür, geri bildirim yumuşar, "güzel olmuş" cümleleri artar.
İkinci sebep ekip tarafında. Yazılmış koda emek gömülür, o ekranı savunma refleksi doğar. Bir haftalık iş çöpe atılırken alınan kararla, yarım saatlik çizim çöpe atılırken alınan karar aynı karar değildir.
Cilalı prototip geç turlara aittir: mikro etkileşim, boşluk, okunabilirlik, hız hissi. Bunlar da ölçülmesi gereken şeyler, ama akış kararı verildikten sonra.
Geri alınamayan değişiklik iterasyon sayılmaz
Döngünün ön koşulu ucuz geri dönüştür. Canlıya çıkan bir değişikliği geri almak yarım gün sürüyorsa, ekip o değişikliği geri almaz, savunur. İterasyon o noktada sona erer ve yerini gerekçelendirmeye bırakır.
Bu yüzden tasarım turlarının teknik zemini kurulmadan döngü kurulmaz: sürüm kontrolü, özellik bayrağı, kademeli açma, değişiklikten önce ve sonra aynı metriğin kaydı. Bayrakla açılıp kapanabilen bir değişiklik, iki turun arasına sıkıştırılmış bir hipotez olur. Geri alma yolu olmayan bir değişiklik ise yalnızca bir karardır, test değil.
Ölçüm tarafında da kolaycılığa kaçmamak gerekir. Tur öncesi ve sonrası farklı metrik bakılırsa, elde kalan şey iyileşme değil, iyileşme hissi olur.
Kaynaklar