Agile Sprintlerinde UX Araştırmasını Ayakta Tutmak

Agile ekiplerinde kullanıcı araştırması zaman yetmediği için değil, bitmiş iş tanımında yer almadığı için eleniyor. Sprint sonunda kimse "bu akış test edilmedi" diye kabulü geri çevirmiyorsa, araştırma ilk sıkışmada listeden düşer. Çözüm daha fazla tasarım toplantısı değil; araştırmayı kabul kriterine yazmak ve ölçeğini sprint boyuna indirmek.

Sprintin bir adım önünde çalışmak

Yaygın tavsiye şu: tasarım ekibi geliştiricilerden bir sprint önde gitsin, sprint başladığında eldeki ekranlar hazır olsun. Tekrar eden işte çalışır. Yeni bir akışta çalışmaz, çünkü önde giden tasarımcı henüz var olmayan bir sistemin davranışına göre karar verir.

Somut hali şöyle. Prototipte filtre anında uygulanıyor, kullanıcı testi de bu haliyle temiz sonuç veriyor. Sprint içinde sorgu 1,2 saniyede dönüyor ve tasarımın dayandığı "anında" varsayımı buharlaşıyor. Geriye ya yükleme göstergesi eklemek ya da filtreyi bir uygula düğmesine bağlamak kalıyor; ikisi de test edilenden farklı bir arayüz. Önde gitme payını bu yüzden bir sprint değil, bir iki madde tutmak daha sağlam.

Otomatikleşen şey test değil, regresyon

"Kullanıcı testlerini otomatikleştirin" tavsiyesi kulağa verimli geliyor, ama otomatikleşen kısım kullanıcı değil, akışın bozulmadığının kontrolü. Bir senaryo script'i insanın ekranı anlayıp anlamadığını söylemez; düğmenin hâlâ orada olduğunu söyler.

CI'a gerçekten koyulabilecek şeyler var:

• Erişilebilirlik denetimi (axe, Lighthouse): kontrast, eksik etiket, bozuk odak sırası gibi makineyle görülebilen hatalar.
• Görsel regresyon: bir CSS değişikliğinin başka bir ekranı bozup bozmadığı.
• Olay kaydı ve huni kırılmaları: hangi adımda kaç kişinin düştüğü.

Bunlar sorunun nerede olduğunu gösterir, nedenini göstermez. "Kullanıcılar ikinci adımda bırakıyor" verisi o adımda neyin anlaşılmadığını açıklamaz; onu ancak birinin ekranı bir kullanıcıya açıp izlemesi açıklar. Erişilebilirlikte de aynı: axe eksik etiketi bulur, ekran okuyucuyla o formu baştan sona doldurmanın mümkün olup olmadığını bulmaz.

Araştırmayı sprint boyuna indirmek

Jakob Nielsen'in "discount usability" dediği yaklaşım hâlâ en pratik çıkış: az katılımcı, kısa oturum, cilalanmamış malzeme. Üç kişiyle yarım saatlik moderasyonlu bir oturum aynı haftanın içinde karar üretir. Rapor yazmaya kalkarsan sprint biter, karar çıkmaz.

Gözden kaçan maliyet katılımcı bulmakta. İki haftalık sprintle yılda 26 sprint eder, her birinde üç kişi, toplam 78 oturum. Bunu her seferinde sıfırdan davet toplayarak kurmak mümkün değil; sabit bir katılımcı havuzu tutmak oturum başına e-posta turu atmaktan çok daha ucuz. Havuz yoksa araştırma ilk yoğun sprintte duruyor ve bir daha başlamıyor.

Kabul kriterinde olmayan iş yapılmaz

Üst yönetim desteği, kaynak darlığı, ekip sirkülasyonu: hepsi gerçek sorun, ama araştırmanın neden atlandığını açıklamıyor. Araştırma, bir maddenin kabulünü engellemediği için atlanıyor. Kabul kriterinde "en az iki kullanıcıyla denendi" satırı varsa o iş yapılır. Yoksa sprint sonunda zamandan ilk kısılan yer burası olur, her seferinde.

Tasarım ve araştırma maddelerini ben teknik borçla aynı backlog'da tutarım. Ayrı bir "UX backlog" açıldığı anda o liste öncelik sıralamasının dışında kalıyor, kimse de ona bakmıyor.

Scrum Master ya da ürün sahibinin işi burada net: test edilmemiş akışı geri çevirmek. Bu yetkiyi kullanan bir rol yoksa, süreçte kaç toplantı olduğu hiçbir şeyi değiştirmiyor.