UX'te İterasyon: Her Turda Tek Bir Soru
İterasyon, tasarımı düzeltmenin adı değil; hangi kararın işe yaradığını ölçülebilir hale getirmenin adı. Çoğu ekip döngüyü kurar, sonra her turda beş şeyi birden değiştirir ve sonucun neden geldiğini toplantıda tartışır. İterasyonu değerli kılan kaç kez döndüğün değil, her turun tek bir soruya cevap vermesi.
Bir turda kaç şey değiştirdin?
İteratif sürecin en pahalı hatası, tek bir sürüme aynı anda çok sayıda değişiklik sığdırmak. Kayıt formunu kısalttın, buton rengini değiştirdin, hata mesajlarını yeniden yazdın, adım göstergesi ekledin, bir de sayfayı hızlandırdın. Tamamlanma oranı yükseldi. Peki hangisi yüzünden?
Bu soru retorik değil, kombinatorik. Aynı turda k değişiklik yaptıysan, sonucu açıklayabilecek boş olmayan değişiklik kümesi sayısı 2^k - 1 kadardır; beş değişiklik için 31 olasılık. Bunların hangisinin gerçek olduğunu veri söylemez, çünkü veri hepsini aynı anda gördü. Elinde kalan tek şey tahmin, ve tahmini ölçüm diye raporlarsan bir sonraki tur yanlış yerden başlar.
Pratik kural: aynı ekranda birden fazla hipotezi aynı turda test etme. Değişiklikler birbirinden bağımsız ekranlardaysa paralel gitmekte sakınca yok, çünkü etkileri ayrı metriklerde görünür.
Prototip nerede test edilir
Tıklanabilir maket, akışın mantığını doğrulamak için yeterli. Gerçek veriyle karşılaşınca çöken şeyleri göstermez: 40 karakterlik ürün adları, boş liste durumu, yavaş yanıt veren arama, iki farklı yazımla girilmiş aynı şehir. Kullanıcı testinde çıkan sorunların önemli bir kısmı tasarımdan değil, verinin gerçek halinden geliyor.
Ben bu yüzden prototip testini genelde geçici bir adrese kurulmuş çalışan sürümle yaparım, maket dosyasıyla değil. Kurulum maliyeti yarım gün, karşılığında test edilen şey tasarımın kendisi değil, tasarımın gerçek veriyle hali oluyor.
Geri bildirim karar vermez
Kullanıcı geri bildirimi, ne yapılacağını söyleyen bir emir değil, nerede tıkanıldığını gösteren bir işaret. İkisini karıştıran ekipler her turda gelen istekleri sıraya dizip uyguluyor ve birkaç tur sonra kimsenin savunamadığı bir arayüz çıkıyor ortaya.
Kullanıcı sorunu tarif etmekte iyidir, çözümü tarif etmekte değil. "Bu ekranda ne aradığımı bulamadım" değerli bir veri. "Buraya bir filtre daha koyun" ise çözüm önerisi, ve genellikle o kişinin o anki işine özel. Talebi olduğu gibi uygulamak yerine altındaki tıkanmayı bul, çünkü aynı tıkanma başka üç kullanıcıda başka üç talep olarak görünüyordur.
Sıralama, listeleme değil
Bir turdan çıkan bulgu listesi hiçbir zaman aynı anda ele alınacak kadar kısa olmaz. Sıralamayı iki eksende yap: sorunun kaç kullanıcıyı durdurduğu ve düzeltmenin uygulamaya ne mal olduğu. İkinci eksen çoğu UX yazısında atlanıyor, oysa karar orada veriliyor. Beş kullanıcıdan üçünü durduran ama veri modelini değiştirmeyi gerektiren bir sorun ile ikisini yavaşlatan ama tek bir metin değişikliğiyle kapanan bir sorun arasında sıralama yaparken, ikincisi bu turda gider, birincisi planlanır.
Bunu tasarımcı tek başına yapamaz. Maliyet tarafını bilen kişi geliştirici, o yüzden bulgu sıralaması ikisinin birlikte oturduğu bir iş.
Döngü ne zaman durur
İterasyonun sonsuz olduğu söylenir, ama pratikte durma noktası bellidir: yeni turlar aynı büyüklükte kazanç getirmemeye başladığında. İlk iki turda tamamlanma oranı ciddi biçimde kıpırdıyorsa döngü çalışıyordur. Üçüncü ve dördüncü turda değişim ölçüm gürültüsünün içinde kalıyorsa, sorun tasarımda değil başka yerdedir; genellikle ürünün o iş için yanlış vaat vermesinde.
O noktada arayüzü cilalamaya devam etmek, tasarım bütçesini en az getirili yere harcamak demek. Döngüyü kapat, soruyu değiştir.
Kaynaklar