Agile Ekiplerde UX: Sprint Ritmi, Ekip Yapısı ve Karar Sahipliği
Agile ekiplerde UX genellikle bir tempo sorunu olarak anlatılır: tasarımcı yetişemez, geliştirici bekler. Sorun tempoda değil, kararın kimde durduğunda. Ekip yapısı ve karar sahipliği netleştiğinde sprint uzunluğu ikinci derece bir ayrıntıya dönüşür.
Bir sprint önde çalışmanın faturası
Standart tavsiye şu: tasarım ekibi geliştirmeden bir sprint önde gitsin. Aritmetiği yapınca tavsiyenin gizli maliyeti çıkıyor. Siz N+1'i tasarlarken N kodlanıyor. N canlıya çıkıp ilk kullanılabilirlik bulgusunu ürettiğinde ekip çoktan N+2'nin tasarımına başlamış olur, yani gerçek kullanım verisi tasarım masasına iki sprint geriden ulaşır. Çevik yöntemin bütün iddiası kısa geri bildirim döngüsüyken, öne geçme tavsiyesi tam da o döngüyü uzatır.
Çözüm öne geçmeyi bırakmak değil, öndeki sprintte ne yapıldığını sınırlamak. Bir sprint ileride yalnızca kaba akış ve ekran çerçevesi çizilmeli. Renk, kopya, boş durum, hata mesajı gibi kararlar kod yazılırken, geliştiricinin yanında verilir. Bu ayrımı yapmayan ekipler öndeki sprintte ürettikleri detaylı tasarımın yarısını çöpe atıyor.
Sprint sıfır: çerçeveyi bir kez kurmak
Projenin başında bir sprintlik çerçeve çalışması, sonraki her sprintte tartışmayı kısaltır. Navigasyon şeması, temel akışlar, bileşen kitaplığının ilk hâli. Kararları genelde doğrudan bileşen kitaplığına yazarak sabitlerim; ekranda anlaşılmış görünen bir kural, kodda bir bileşene karşılık gelmiyorsa üçüncü sprintte iki farklı yorumla karşınıza çıkar. Kitaplıktaki buton varyantı bir tasarım tercihi değil, sonraki kırk ekranın sözleşmesidir.
Çerçeve yılda bir iki kez gözden geçirilmeli. Daha sık yapılırsa ekip sürekli temel tartışır, hiç yapılmazsa arayüz özellik özellik dağılır.
Merkezi ekip, dağıtık ekip, matris
Teslimat hızında dağıtık yapı kazanır. UX uzmanı ekibin içinde oturuyorsa karar saatler içinde çıkar, merkezi havuzda ise talep sırası bekler. Standart üretmekte, işe alımda ve yeni uzmanın yetişmesinde merkezi yapı kazanır; tek başına çalışan tasarımcının kalitesini kimse denetlemez.
Matris ikisini birden verir, ama tek şartla: uzman sayısı ekip sayısına yetiyorsa. Yetmiyorsa matris, insanları üç projeye bölmenin kibar adı olur ve hiçbirine zamanında yetişemezler. Beş geliştirme ekibine iki tasarımcı düşüyorsa yapılacak şey model seçmek değil, ekiplerden üçünde UX'siz ilerleneceğini açıkça kabul etmektir. Örtük hâli daha pahalıya patlıyor.
Bağlantı kişisi ne zaman gerekir
Tek ekipli projede anchor rolü gereksiz bürokrasidir. Üç dört paralel ekipten sonra biri gereksinim ve karar kaydını tutmak zorunda, yoksa aynı problem iki ekipte iki farklı arayüzle çözülür. Bu rolün işi karar vermek değil, verilen kararın nerede yazılı olduğunu bilmek.
Ucuz test olmadan hiçbiri işlemez
Sprint içinde tamamlanamayan test, yapılmayan testtir. Kağıt prototip, tıklanabilir taslak, koridorda yakalanan beş kişi: bunlar bir günde biter ve o sprintin kararını değiştirebilir. Nielsen'in az katılımcıyla çok tur önerisi burada pratik bir gerekçeye oturuyor, çünkü on beş kişilik tek bir çalışmanın sonucu geldiğinde ilgili sprint kapanmış olur.
Agile ile UX arasındaki gerilim yöntem farkından değil, karar hızı farkından çıkıyor. Tasarım kararını kod kararıyla aynı hızda alabilen ekipler bu gerilimi hiç yaşamıyor.