Lean UX ve Agile: Araştırmayı Sprintin Önüne Almak
Lean UX ile Agile'ı birlikte yürüten ekiplerin çoğu aynı yerde tıkanır: sprint iki hafta, araştırma ise sonucunu iki hafta sonra veren bir iş. İkisini tek takvime sıkıştırmaya çalıştığınızda araştırma her seferinde kesilen kalem olur. Çözüm UX'i sprintin içine sığdırmak değil, bir sprint önüne almak.
Araştırma sprintin içine değil, önüne girer
Sık verilen iki tavsiye birbirini yer. Biri, UX işlerinin de ürün backlog'unda yazılım işleri gibi yer alması gerektiğini söyler. Diğeri, kullanıcı araştırmasını sprint başlamadan bitirmenizi. İkisi aynı sprint için birden geçerli olamaz: aynı sprintin backlog'una konan araştırma işi, o sprintte tasarlanacak ekranın girdisini üretmez, çıktısı ancak sprint kapanırken masaya gelir.
Pratikte işleyen düzen ikili akış. Araştırma ve keşif işleri N'inci sprintte yürür, o bulguları tüketen tasarım ve geliştirme işleri N+1'de planlanır. Böylece araştırma "zaman kalırsa" yapılan iş olmaktan çıkıp kendi sprintinde teslim tarihi olan bir işe dönüşür. Bu ayrımı kurmadan UX'i backlog'a eklemek, yalnızca kesilecek kalemin adını listeye yazmaktır.
İki akış aynı çerçeveye zorlanmasın
Keşif işi planlanabilir değildir. Beş kişiyle görüşme ayarlarsınız, üçüncüsünde ilk hipotez çöker ve soru seti değişir. Sprint sınırı bu işi ikiye bölmekten başka bir şey yapmaz.
Teslimat akışını Scrum'da tutup keşif akışını Kanban'a almak, ikisini tek çerçeveye sıkıştırmaktan daha iyi çalışır. Kanban'da izlediğiniz şey sprint kapasitesi değil, aynı anda açık kaç keşif işi olduğudur; araştırmadaki gerçek kısıt da budur. SAFe'yi birkaç ekipten küçük yapılarda kurmak ise çözdüğü sorundan fazla toplantı üretir.
Düşük sadakat estetik tercih değil, vazgeçme maliyeti
Kağıt taslak, tıklanabilir akış, kodlanmış ekran. Aradaki fark görsel kalite değil, fikirden vazgeçmenin maliyeti. Kağıt taslağı test odasında buruşturup atmak bedavadır. Aynı bulgu kodlanmış ekranda çıktığında ekip ekranı savunmaya başlar (bunu tasarımcı inadı saymıyorum, harcanan emeğin doğal sonucu). Bu yüzden hipotezin en zayıf olduğu yerde sadakati düşük tutun; kod, hipotez ayakta kaldıktan sonra gelir.
MVP de buraya oturur: küçültülmüş ürün değil, tek bir soruyu cevaplayacak kadar küçük ürün. Cevaplayacağı soru yazılmadan başlanan MVP, sadece eksik üründür.
Ölçüm araçları aynı şeyi ölçmez
Agile ekiplerde sık rastlanan karışıklık, performans metriklerinin kullanıcı araştırmasının yerine geçmesi. Lighthouse skoru sayfanın ne kadar hızlı yüklendiğini söyler, kullanıcının formun üçüncü adımında neden durduğunu söylemez. İlki mühendislik bulgusudur, ikincisi ancak birinin o formu doldurmasını izleyerek ortaya çıkar. Skor yükselirken tamamlama oranının düşmesi mümkündür ve bu bir çelişki değil, iki ayrı şeyi ölçtüğünüzün kanıtıdır.
Backlog'daki UX işi ne zaman bitmiş sayılır
Yazılım işinin bitmiş sayılma koşulu vardır, UX işinin genelde yoktur. Sonuç olarak araştırma kalemleri ya hiç kapanmaz ya da kimse fark etmeden kapanır. Bir araştırma işini backlog'a yazarken iki şeyi aynı satıra koyun: hangi soruyu cevaplıyor ve çıktısı ne olacak. Çıktısı tanımsız araştırma, sprint gözden geçirmesinde gösterilecek bir şey üretmediği için bir sonraki planlamada ilk kesilen iş olur.
Retrospektifte UX'e dair sorulacak soru
Retrospektifler çoğu ekipte süreç muhasebesine döner: kapasite, engeller, teslim tarihleri. UX tarafında işe yarayan soru daha dar: bu sprintte verdiğimiz hangi tasarım kararı bir kullanıcı gözlemine dayanıyordu, hangisi odadaki en kıdemli kişinin tercihine? Terazi ikinci tarafa ağır basıyorsa yaptığınız şey Lean UX değil, hızlandırılmış tahmindir.