Agile UX: Tasarımı Sprint Ritmine Sığdırmak
Çevik ekiplerde tasarım genelde yöntemden değil takvimden tıkanır. İki haftalık sprintin içine araştırma, prototip, test ve geliştirme sırayla sığmaz; biri bitmeden diğerinin başlaması gerekir. Çözüm daha fazla toplantı değil, tasarımı geliştirmenin bir sprint önünde çalıştırmak.
Tasarımı bir sprint önden çalıştır
Aritmetik basit. İki haftalık sprint 10 iş günü. Klasik tasarım sprinti 5 gün: araştırma, fikir, prototip, test. Bunu aynı sprintin içine koyarsan geliştirme ekibi, kapsamı ancak 5. günün akşamı netleşen bir işi kalan 5 günde bitirmek zorunda kalır. Her sprintte kapsam ortadan değişir, kestirim tutmaz, sprint sonunda yarım iş devredilir.
Sprint N'de tasarlananın sprint N+1'de kodlanacağını kabul et. Kural şu: backlog'a girmeden önce her madde en az bir kez prototipe dönüşmüş ve bir kullanıcıya gösterilmiş olsun. Tasarımcı bir sprint önde çalışırken geliştirici boş oturmaz, önceki sprintte doğrulanmış işi yapar.
Bunun bedeli var: tasarımcı sürekli iki sprint arasında bölünür, hem gelecek işi hazırlar hem şu anda kodlanan işin sorularını cevaplar. Takvimde bu ikinci iş için yer ayır, yoksa "hızlı bir soru" diye gelen mesajlar tasarım gününü yer.
Prototipi neyi cevaplamak için yaptığını yaz
Her prototipin tek bir sorusu olsun ve o soruyu yapmadan önce bir cümleyle yaz: "Kullanıcı filtreyi ilk ekranda bulabiliyor mu?" Sorusu olmayan prototip demoya döner, demo da geri bildirim yerine beğeni toplar.
Sorunun dar olması prototipin de dar olmasını sağlar. Tıklanabilir tek akış yeterliyse tasarım aracında kalın; gerçek veriye, gerçek gecikmeye, gerçek hata durumuna bağlı bir soru soruyorsan basit bir HTML sayfası çoğu tasarım aracından daha dürüst cevap verir.
Prototipte yazdığım kodu ürüne taşımam. O kod bir soruyu cevaplamak için yazıldı, yaşamak için değil; içinde hata yönetimi yok, kenar durumları yok, testi yok. Cevabı aldıktan sonra doğru olan onu silmek, tekrar yazmanın maliyeti sanılandan küçüktür.
Testten ne çıkar, ne çıkmaz
Beş kişiyle yapılan bir test "kullanıcıların yüzde kaçı" sorusuna cevap vermez. Arayüzün nerede kırıldığını gösterir, ne sıklıkta kırıldığını değil. Sonucu yüzdeyle raporlarsan aslında sayı uydurmuş olursun ve o sayı toplantıdan toplantıya dolaşarak karar dayanağına dönüşür.
Sıklık sorusunun cevabı testte değil üründe: olay kaydı, hata oranı, akışın adımları arasındaki düşüş. Küçük testler nereye bakacağını söyler, ölçüm de ne kadar olduğunu. İkisini karıştırmayan ekip, tasarım tartışmalarının çoğunu veriyle kapatır.
Dokümantasyonu azaltmanın sınırı
Çevik yaklaşımın "gereksiz dokümanı bırak" tavsiyesi doğru, ama iteratif çalışmayla doğrudan çelişen bir tarafı var. Aynı ekran üçüncü kez elden geçtiğinde, ilk turda neden o kararın verildiğini kimse hatırlamaz. Kayıt yoksa tartışma sıfırdan açılır ve daha önce elenmiş seçenek yeniden denenir.
Uzun tasarım dokümanı yazma, karar günlüğü tut. Satır başına üç şey yeter: ne denendi, ne oldu, ne karar verildi. Bir sprintte bu on satırı geçmez ve altıncı ayda ekibe kazandırdığı zaman, tuttuğu yerin çok üstündedir.
Paydaşı süreç içinde tut
Sprint sonunda yapılan büyük sunum, geri bildirimi işe yaramayacak kadar geç getirir. Paydaşı test seansına izleyici olarak çağır. Kendi kullanıcısının aynı düğmeyi üç kez ıskaladığını izleyen bir yönetici, o düğmeyi savunan raporu okuyan yöneticiden farklı davranır.
Kaynaklar