Konu Başlıkları
Yükleniyor...

Kullanıcı Geri Bildirimini Talep Listesine Çevirmeden Okumak

Geri Bildirimde Şikâyet Sayısı Yerine Neye Bakmalı?

Geri bildirim toplamak kolay, doğru okumak zor. Kullanıcıdan gelen cümlelerin çoğu talep değil, bir tıkanmanın belirtisidir; talep listesine çevrildiği anda arkasındaki sorun kayboluyor. Bir de forma cevap verenlerin ürünü kullanan herkesi temsil etmemesi var, bu tek başına pek çok kararı yanlış yöne çeviriyor.

Talep ile geri bildirim aynı şey değil

Kullanıcı “şuraya bir buton koyun” dediğinde elinizde bir çözüm önerisi vardır, problem tarifi değil. Öneriyi yapan kişi sistemin geri kalanını görmüyor: o butonun hangi durumları doğuracağını, hangi ekranlarda tutarlılık borcu bırakacağını bilmesi de beklenmez. Sorulacak soru tek: bunu isterken tam olarak ne yapmaya çalışıyordunuz?

Bir talebi karşılamak tek seferlik iş de değil. Eklenen her seçenek, sonraki her değişiklikte yeniden test edilecek, anlatılacak, bozulduğunda tamir edilecek bir yüzey bırakır. “Küçük bir ekleme” cümlesi genelde bu yüzey hesaba katılmadan kurulur.

Gelen istekleri kendi başlıklarıyla değil, kullanıcının tıkandığı ekranın altında toplamayı tercih ederim; aynı ekranda biriken beş ayrı istek çoğu zaman tek bir tasarım hatasını gösterir.

Sessizlik memnuniyet sayılmaz

“Binlerce kişi bu özelliği sorunsuz kullanıyor, demek ki sorun yok” cümlesi niceliksel duruyor ama ölçtüğü şey şikâyetin yokluğu. Bir akışta takılan kullanıcının ilk tepkisi form doldurmak olmaz; geri döner, başka yolu dener ya da bırakır. Bakılacak sayı o adımdaki terk oranıdır, gelen kutusundaki mesaj adedi değil.

Şikâyet sayısını yine de kullanacaksanız kullanım sayısına bölün. Yeni yayına alınmış bir ekran için gelen üç şikâyet, yıllardır çalışan bir ekrandan gelen otuz şikâyetten daha ağır bir sinyal olabilir.

Aynı yanılgı testlerde de var. Bir sorunu tek bir kullanıcının ortaya çıkarma olasılığı yüzde 30 ise, beş kişilik bir oturumda o sorunun hiç görünmeme olasılığı 0,7’nin beşinci kuvvetidir, yani yaklaşık yüzde 17. Beş kişide çıkmadı demek, yok demek değil; sık karşılaşılan sorunlar için beş kişi yeterli, nadir ama pahalı hatalar için değil.

Ne aradığınızı söyleyin, cevabı söylemeyin

Katılımcıya araştırmanın konusunu açıkça söylemek veriyi bozmaz, tam tersine konu dışı şikâyetleri azaltır. Bozan şey beklediğiniz cevabı ima etmektir. “Bu ekranı daha kolay buldunuz, değil mi” diye sorduğunuzda aldığınız yanıt kullanıcının deneyimini değil, sizi memnun etme eğilimini ölçer.

Görev verin, izleyin, sustuğu yerde susun. Kullanıcının nerede durakladığı, nereye yanlış tıkladığı, hangi adımı iki kez tekrarladığı; bunların hiçbiri sözlü ifadeye ihtiyaç duymaz. Söylenen ile yapılan arasındaki fark da genelde tam burada görünür hale gelir.

Önceliklendirme oy sayımı değildir

Talepleri sayıp en çok tekrarlananı yapmak kolay bir kural, ama sayım kimin konuştuğuna bağlı. En çok yazan kullanıcılar genelde en ileri seviyedekiler; onların istediği esneklik, ürüne yeni gelen kişinin ilk beş dakikasını zorlaştırır.

İşleyen ayrım şu: bir geri bildirim mevcut bir işi yapmayı engelliyorsa sıraya girer, mevcut işi farklı yapmayı öneriyorsa beklemeye alınır. Birincisi hata, ikincisi tercih. İkisini aynı listede tutmak, yol haritasını en yüksek sesli kullanıcının belirlemesiyle sonuçlanır.

Kaynaklar