Lean UX: Varsayımdan MVP'ye Hızlı Karar Döngüsü

Lean UX, ağır dokümantasyonu bırakıp tasarım kararını erken geri bildirime bağlayan bir çalışma biçimi. Çevik ekiplerde tutmasının nedeni basit: her sprintte tek bir varsayımı test edilebilir hale getiriyor. Asıl kazanç hızda değil, yanlış yolda ne kadar erken durabildiğinde.

Lean UX neyi değiştirir

Klasik UX'te önce kapsamlı belge, sonra tasarım, en sonda test gelir. Lean UX bu sırayı ters çevirir: elinde bir problem ve birkaç varsayım varken küçük bir şey çıkarır, kullanıcıya gösterir, gördüğüne göre yönünü düzeltir.

Pratikte bu, ekibin ortasındaki dokümanın küçülmesi demek. Tasarımcı, geliştirici ve ürün sahibi aynı varsayım listesine bakar; kimse kırk sayfalık gereksinim dosyasını okumayı beklemez. Karar masada verilir, belgeye değil koda geçer.

Varsayımı hipoteze çevir

Başlangıç noktası bir problem ve o probleme dair varsayımlar. Şu dört soruyu ekipçe yanıtla, gerisini erteleme:

• Kullanıcı kim ve bunu hangi anda kullanacak?
• En kritik tek fonksiyon ne?
• Bu işi batırabilecek en büyük risk hangisi?
• Hangi varsayımı yanlış çıkarsa geri kalan her şey çöker?

Son soru en can alıcısı. En riskli ve en bilinmeyen varsayımı öne al, önce onu test et. Zaten emin olduğun bir varsayımı test etmek zaman kaybı.

Sonra varsayımı test edilebilir bir hipoteze bağla: “Şuna inanıyoruz, çünkü... Doğruysa şu davranışı göreceğiz.” Buradaki gizli fayda, tasarımdaki zevk tartışmalarını kesmesi. “Bence bu buton daha güzel” cümlesi, “kullanıcı bu adımda takılıyor mu” sorusunun yanında tutunamaz.

MVP en küçük test, en ucuz ürün değil

MVP'yi “özelliklerin kırpılmış hali” sanmak yaygın hata. MVP, bir soruya cevap veren en küçük şey. Sorusu olmayan MVP sadece eksik üründür.

Bir ekip projesinde tam bu yüzden üç haftalık bir akışı yayına almadan attık: hipotezi beş kullanıcıyla test ettik, hiçbiri bizim çizdiğimiz yolu izlemedi. Erken öğrenmek o üç haftayı geri getirmedi ama sonraki iki ayı kurtardı.

Hipotezin çıkmazı: kanıt mı, sinyal mi

Lean UX'in kendi içinde bir gerilim var ve çoğu rehber bunu atlıyor. Hipotez formatı “kanıtlanacaktır” der; sprint temposu ise sana kanıt için yeterli örneklem vermez. Beş kişilik bir testte gördüğün şey yön gösteren bir sinyaldir, istatistiksel kanıt değil.

Bunu karıştırmak Lean UX'in en sinsi başarısızlığı: zayıf sinyali kanıt yerine koyup yanlış yöne emin adımlarla yürümek. Kuralı şöyle kur: küçük testler bir yolu elemek için yeterlidir, bir yolu garantilemek için değil. Bir özelliği öldürmek için beş kullanıcı yeter; onu ölçekte doğru kabul etmek için sayıya ihtiyacın var.

Çevik ile nasıl oturur

Lean UX ile Agile aynı ritimde çalışır. Her iterasyonun sonunda bir hipotez ya doğrulanır ya elenir, tasarım bir sonraki sprintte buna göre güncellenir. Araştırmayı tek bir UX uzmanına yıkma; geliştirici de test odasında otursun, çünkü kullanıcının nerede takıldığını kendi gözüyle gören biri o düzeltmeyi ikinci kez tartışmaz.

Kısa pratik notlar

• Belgeyi süreç için değil, karar unutulmasın diye tut. Kimse okumuyorsa kısalt.
• Büyük sürüm yerine küçük ve sık güncelleme çıkar; hatayı erken ve ucuza yakalarsın.
• Anketi sadeleştir. Üç net soru, on muğlak sorudan çok iş görür.
• Yöneticiyi sürecin içine al; onayı sonda değil, varsayım aşamasında iste.