Prototip Testinde Geri Bildirim Toplamak: Yöntemler ve Sınırları

Prototip testinin çıktısı, topladığınız geri bildirim kadar iyi olur. Buraya kadar herkes hemfikir. Sıkıntı, yaygın toplama yöntemlerinin neyi yakaladığı kadar neyi kaçırdığının pek konuşulmaması. Aşağıdakiler işe yarayan klasik yöntemler, her birinin nerede tıkandığıyla birlikte.

Kaç kişiyle test ettiğiniz değil, kaç farklı gruptan olduğu

“Beş kullanıcı yeter” cümlesi sektörde neredeyse bir slogan. Kaynağı gerçek: Jakob Nielsen'in beş kullanıcı savunması. Ama o yazının sessizce yaptığı bir varsayım var, beş kişinin tek ve homojen bir kullanıcı grubundan gelmesi. Yani beş, toplam katılımcı sayısı değil, segment başına düşen sayı.

Bu ayrım, tavsiye listelerinde hemen kayboluyor. Tipik kullanıcıyı da alın, uç kullanıcıyı da alın, iki farklı pazardan da alın deniyor; ardından beş kişilik bir oturum kuruluyor. Tipik/uç ile iki pazarı çaprazlarsanız dört hücreniz olur, beş katılımcıda hücre başına bir kişiden biraz fazlası kalır. Tek kişinin söylediği şey segment bulgusu değildir, anekdottur. Çeşitlilik istiyorsanız oturum sayısını artırmanız gerekir, aynı oturumun içini karıştırmanız değil.

İç paydaş onayı da bu tabloya karışmamalı. Ürünün teknik olarak yapılabilir olup olmadığı, teslim tarihinin tutup tutmadığı gerçek sorular ama bunlar kullanılabilirlik verisi üretmez. Aynı toplantıda ikisini birden yaparsanız, kullanıcının takıldığı yer masadaki en kıdemli kişinin fikriyle aynı ağırlığa iner.

Feedback Capture Grid: notu kim tutuyorsa filtreyi o koyar

Dört bölmeli basit bir tablo. Sol üst beğeniler, sağ üst eleştiriler, sol alt kullanıcının soruları, sağ alt fikirler. Değeri, tabloda eleştiri için ayrılmış boş bir kutu olmasından geliyor. Not tutan kişi, oturumu izlerken duyduğunu nereye yazacağını bildiği için farkında olmadan yumuşatmıyor.

Yaygın tavsiye şu: bir bölme boş kalıyorsa daha çok soru sorup doldurun. Bunu ters buluyorum. “Sorular” kutusunun boş kalması bir eksiklik değil, bulgunun kendisi olabilir; kullanıcının kafası karışmamıştır. Zorlayarak soru ürettirdiğinizde elinizde gerçek olmayan bir kayıt kalır ve o kayıt bir sonraki iterasyonda gerçekmiş gibi işlem görür. Boş kutuyu boş bırakın, oturum sonunda neden boş kaldığını tartışın.

I Like, I Wish, What If ve “keşke” tuzağı

Katılımcıdan üç kalıpla konuşmasını istersiniz: beğendiğim, keşke olsaydı, ya şöyle olsaydı. Yöntemin gerçek faydası psikolojik. Eleştiriyi sosyal olarak ucuzlatır, kimse tasarımcıyı kırdığını hissetmeden “keşke” diyebilir.

Ortadaki kalıbın bir bedeli var ama. “Keşke” demek, kullanıcıyı teşhisten alıp reçeteye iter. Karşınızdaki artık ne yaşadığını değil, ne yapılması gerektiğini anlatır ve siz semptomu kaybedersiniz. “Keşke buton üstte olsaydı” cümlesinin altında en az iki farklı sorun yatabilir: butonu hiç göremedi, ya da akışın o adımında bir butonun bulunmasını bekliyordu. İkisinin çözümü aynı değil. Her “keşke” için bir adım geri sarın, bunu düşündüren an neydi diye sorun. Üçüncü kalıp, What If, pratikte en zayıfı (yine de bırakıyorum, oturumun gerginliğini almakta işe yarıyor).

Açık uçlu soru, tarafsız soru demek değil

Kullanıcı testi rehberlerinde sık geçen bir örnek var: “Bunu nasıl buldunuz?” yerine “Bu özelliği sizce nasıl daha kullanışlı hale getirebiliriz?” sorun deniyor, gerekçe olarak da ikincisinin daha açık uçlu olması gösteriliyor. İkinci soru gerçekten daha açık uçlu. Ama daha az tarafsız, çünkü içine iki varsayım gizlenmiş: özellik şu anda yeterince kullanışlı değil, ve kullanıcı bunun tasarımını yapacak kişi. Katılımcı ikisini de kabul edip size nazik bir öneri üretir, siz de kendi cümlenizin yankısını veri sanırsınız.

Testin en değerli dakikaları soru sormadığınız dakikalardır. Görevi verin, susun, ellerine bakın. Nerede duraksadığı, nereye tıklamaya çalıştığı, hangi ekranda geri döndüğü hiçbir sorunun getiremeyeceği kadar temiz bir sinyaldir. Prototipin bir yerini açıklamak zorunda kaldığınız her an da ayrı bir bulgudur; arayüz o noktada sizin ağzınızla konuşuyor demektir ve gerçek kullanıcının yanında siz olmayacaksınız.

Toplamak kolay kısmı, karara bağlamak zor kısmı

Geri bildirimi kategorilere ayırıp arşivlemek düzenli görünür ama tek başına hiçbir şeyi değiştirmez. Her maddenin bir sonuca bağlanması gerekir ve sonuç üç taneden biridir: değiştiriyoruz, bilinçli olarak reddediyoruz, ya da karar veremiyoruz ve ölçeceğiz. Reddedilenleri gerekçesiyle yazmak, listenin en çok işe yarayan parçası. Aynı geri bildirim üçüncü kez geldiğinde açıp bakarsınız, gerekçe hâlâ geçerli mi diye.

Test sonrası ekipçe hikaye paylaşmak, post-it'lerle duvar doldurmak empati için güzel bir ritüel. Karar üretmez. O duvardan çıkan hiçbir şey backlog'a düşmüyorsa, güzel bir öğleden sonra geçirmişsiniz demektir.