Lean UX Araştırmasında Hızı Gerçekten Artıran Alışkanlıklar

Lean UX'in vaadi basit: rapor yazmaya harcanan zamanı kullanıcıyla konuşmaya aktarmak. Uygulamada bu, araştırmayı sprint temposuna sığdıran birkaç alışkanlığa iniyor. Aşağıdakiler işe yarayanlar; aralarında birbiriyle sessizce çelişen bir çift de var.

Fark, dokümanın azlığında değil

Lean UX genelde “az doküman yaz” diye özetleniyor. Yanlış özet. Fark, kararın nereye dayandığında: klasik süreçte karar araştırma raporunun tamamlanmasını bekler, Lean UX'te karar bir sonraki kullanıcı görüşmesine kadar geçerli sayılan bir varsayımdır. Doküman az çıkıyorsa bu sonuçtur, amaç değil.

Testi takvime bağlayın

Araştırmanın sprint içinde kaybolmasının tek sebebi var: kimse için sabit bir günü yok. Ayda iki gün, ya da her sprintin ortasında yarım gün, katılımcı bulunsun bulunmasın bloke edilirse test yapılır. “Prototip hazır olunca çağırırız” diyen ekipler çağırmıyor.

Küçük ve sık olan, büyük ve seyrek olanı yener. On beş kişilik tek bir çalışma yerine üç kez beş kişiyle oturursanız aradaki iki iterasyonun da ne getirdiğini ölçmüş olursunuz.

Veriyi erken ve ham paylaşın

Bulguyu rapora dönüştürmeden paylaşın. Test biter bitmez ekibe giden üç maddelik bir not, iki hafta sonra gelen otuz sayfalık dosyadan daha çok karar değiştirir. Notun içinde yorum değil gözlem olsun: kullanıcı hangi ekranda durdu, ne aradı, nereye tıkladı.

Ayrıntılı analiz gerekiyorsa isteyen zaten çıkar. Çıkmıyorsa yazmayın.

Test planı bir sayfayı geçmesin

Plan üç şeyi netleştirsin: hangi soruyu cevaplıyoruz, kullanıcıya hangi görevi veriyoruz, hangi sonucu varsayımımızın yanlış olduğuna sayacağız. Üçüncüsü çoğu planda yok, oysa testin bir şey öğretip öğretmeyeceğini belirleyen o.

Geliştirici odada olsun

Kullanıcının aynı butonu üçüncü kez ıskaladığını izleyen geliştirici, aynı bulguyu iş takip kaydında okuyan geliştiriciden farklı davranır. Bir de maliyeti odada söyleyebilir: “bu akışı değiştirmek iki gün sürer” ile “bu zaten tek satırlık bir sıralama değişikliği” arasındaki farkı tasarımcı tahmin ederek öğrenemez, öğrenmeye kalkarsa yanlış yerden vazgeçer. (Beş maddenin içinde en çok bunu önemsiyorum.)

Hazır rapor şablonunun iki ucu keskin

Şablonu önceden hazırlamak zaman kazandırır, orası doğru. Ama listenin içinde bir çelişki var: bir yanda “planı sadeleştir, varsayımı erken bırak” deniyor, öbür yanda “hangi veriyi hedeflediğini test öncesinde netleştir”. İkincisi, doldurulacak kutuları baştan belirlemek demek. Kutular belirlendiğinde kullanıcının söylediği ama hiçbir kutuya uymayan şey nota girmez, çünkü onu yazacak yer yoktur.

Çözüm şablonu atmak değil. Sonuna “beklemediğimiz şeyler” diye boş bir alan koyun ve her oturumda oraya en az bir satır yazılsın. Sürekli boş kalıyorsa oturumu izleyen kişi not almıyordur.

Hangisinden başlamalı

Beşini birden kurmaya çalışan ekip hiçbirini kuramaz. Sabit test gününden başlayın. Diğer dördü, elinizde düzenli akan gözlem olduğunda kendiliğinden gerekli hale gelir; o gözlem yoksa hepsi boşa işletilen bir süreçtir.