Kullanıcı Odaklı Tasarımı Çevik Sprintlere Sığdırmak
Kullanıcı odaklı tasarım ile çevik geliştirme aynı takvimi paylaşmakta zorlanır. Araştırma yavaş ilerler, sprint iki haftada kapanır, kullanıcı testi de çoğu ekipte sprint sonuna sıkışan ve ilk gecikmede listeden düşen iş olur. Çözüm ikisinden birini feda etmek değil, araştırmanın ritmini geliştirmenin ritminden ayırmak.
Çatışma bütçede değil, takvimde
UCD'nin ihtiyaç duyduğu şey gözlem, sentez ve tekrar. Çeviklikte ise iki haftalık bir kutu var ve o kutunun sonunda çalışan bir şey çıkması bekleniyor. Aynı sprintin içinde hem araştırma yapmaya hem o araştırmanın sonucunu koda dökmeye çalışan ekip ikisini de yarım bırakır.
Bütçe tartışması genelde bunun üstünü örter. “UX'e ayıracak paramız yok” cümlesinin altında çoğu zaman “araştırmayı ne zaman yapacağımızı planlayamadık” yatar. Para değil sıra sorunu.
Araştırmayı bir sprint öne alın
Pratikte işleyen tek düzen şu: tasarım ve araştırma, N+1'inci sprintin işini N'inci sprintte hazırlar. Geliştirme N+1'de hazır girdiyle çalışır. Böylece geliştirme araştırmayı beklemez, araştırma da sprint sonuna sıkışmaz. Testi sprintin son gününe iliştirmek yerine bir sprint öne çekin (sprint sonu testi bence çoğu ekipte kağıt üzerinde kalıyor, ilk daralmada silinen madde hep o oluyor).
Bunun bir bedeli var. Tasarım ekibi sürekli bir sprint ilerideki belirsizlikle çalışır ve kapsam değişince hazırladığı iş çöpe gider. Kabul edilebilir bir kayıp, çünkü alternatifi belirsizliği geliştirme sprintinin ortasında keşfetmek.
Küçük örneklemin matematiği
“Beş kullanıcı yeterli” tavsiyesi bir kuraldan değil basit bir modelden geliyor. Her katılımcı sorunların L kadarını buluyorsa, n katılımcının toplamda bulduğu oran 1 eksi (1-L) üzeri n olur. L değeri 0,30 ise beş kişide 0,70 üzeri 5, yani yaklaşık 0,17 kalır; bulunan oran %83 civarıdır. Kulağa iyi geliyor.
Sınır şurada: L küçüldükçe eğri hızla düşer. Arayüz olgunsa ve kalan sorunlar seyrekse, mesela L 0,15 ise beş kişi ancak %56'ya ulaşır. Üstelik model tek bir kullanıcı kitlesi varsayar. İki farklı segmente (diyelim son kullanıcı ve yönetici rolü) hitap eden bir üründe beş kişi toplamda değil, segment başına gerekir. Toplam beşle yaptığınız test, ikinci segmentin sorunlarını neredeyse hiç görmez.
Prototip mi, bayrağın arkasında gerçek arayüz mü
Yüksek çözünürlüklü tıklanabilir prototip hazırlamak, mevcut bir ekranda küçük bir değişikliği özellik bayrağı arkasında canlıya çıkarmaktan çoğu zaman daha pahalıdır. Var olan akışın iyileştirilmesini konuşuyorsanız gerçek arayüzü açın, ölçüm de kendiliğinden gelsin. Prototip, henüz kodda karşılığı olmayan yeni bir akışı tartışırken değerli; orada da kağıt üstünde çizilen ekranın altyapıda ne kadar iş çıkardığını tasarım aşamasında sormak gerekir, sprint planlamada değil.
Dokümantasyonu kesmeyin, kısaltın
Çevik ekiplere sık verilen “dokümantasyona vakit ayırma” tavsiyesi, dağıtık çalışan ekiplerde kendi içinde çelişir. Yazıya geçmeyen geri bildirim, testte olmayan herkes için hiç var olmamıştır. Uzun rapor yerine sprint başına yarım sayfa tutun: kimlerle konuşuldu, ne gözlendi, hangi karar değişti. Karar değişmediyse yazmaya da gerek yok.
Testi kabul kriterine bağlayın
Kullanıcı testinin sprintten düşmemesinin tek güvencesi, onu ayrı bir iş kalemi olmaktan çıkarmak. Hikayenin tanımına “üç katılımcı görevi yardımsız tamamladı” gibi bir kabul kriteri yazıldığında test, yapılırsa iyi olur listesinden çıkıp işin bitmiş sayılma şartına dönüşür. Retrospektiflerde konuşulacak konu da böylece “teste vakit bulamadık” değil, “kriteri neden karşılayamadık” olur.
Kaynaklar