UX Araştırmasında Destek ve Satış Kayıtlarını Doğru Okumak
UX araştırması denince akla tasarımcının bir kullanıcıyla oturup yaptığı görüşme gelir. Oysa şirkette kullanıcıyla en çok konuşan iki grup destek ve satış ekipleridir; ikisi de her gün, hiçbir yere kaydedilmeyen gözlem üretir. Bu gözlemleri toplamak bir iş. Ne göstermediklerini bilmek başka bir iş, ve genelde atlanan da o.
İki farklı veri türü
UX araştırmasında elinize geçen veriyi ikiye ayırmak işi kolaylaştırır. Birincisi davet edilmiş veridir: kullanıcı testi, anket, odak grup. Kimi çağıracağınıza siz karar verirsiniz, soruyu siz sorarsınız, örneklemi siz kurarsınız. İkincisi kendiliğinden oluşan veridir: destek talepleri, satış görüşmesi notları, sosyal medyaya düşen şikayetler. Bu ikincisini kimse tasarlamaz, kendi kendine birikir.
Kendiliğinden oluşan verinin cazip yanı bedava ve bol olmasıdır. Zayıf yanı ise örneklemini seçememenizdir. Destek kuyruğunuzda kimin olduğuna siz karar vermiyorsunuz, kullanıcı karar veriyor. Aradaki farkı görmezden gelip destek kayıtlarını temsili bir kullanıcı örneklemi gibi okumak, bu iki ekiple çalışırken yapılan en yaygın hata.
Destek kayıtlarının kör noktası
Bir kullanıcının size destek talebi açması için iki şeyin aynı anda olması gerekir: sorunu kendi başına aşamamış olacak, ve size yazmaya değecek kadar bu işe bağlı olacak. Kayıt formunda tıkanan, sinirlenip sekmeyi kapatan ve bir daha dönmeyen kullanıcı bu iki şartın ikincisini sağlamaz. Hiçbir iz bırakmaz.
Sonucu şu: destek kuyruğunda en sık görünen sorunlar, kullanıcının çözmek için uğraştığı sorunlardır. Yani vazgeçmediği sorunlar. En ağır UX problemleriniz, tanım gereği, destek kayıtlarında en az görünenler arasında olabilir. Etiketleme sisteminizi ne kadar iyileştirirseniz iyileştirin bu boşluk kapanmaz, çünkü sorun kaydın kalitesinde değil, kaydın hiç oluşmamasında.
Bu yüzden destek verisini tek başına bırakmayın. Yanına terk noktalarını gösteren bir huni analizi, birkaç oturum kaydı ve satın almayan kullanıcıya sorulmuş tek bir soru koyduğunuzda tablo tamamlanmaya başlar. Destek kuyruğu size sorunun ne olduğunu anlatır; kimin sessizce gittiğini başka yerden öğrenirsiniz.
Etiketleme: az sayıda etiket, tutarlı kullanım
Destek kayıtlarını sonradan analiz edebilmek için sınıflandırmanız gerekir. Burada standart tavsiye ayrıntılı bir etiket şeması kurmaktır, ki pratikte bu çoğu zaman ters teper. Etiket sayısı arttıkça iki temsilcinin aynı talebe aynı etiketi verme ihtimali düşer, ve tutarsız etiketlenmiş bir veri kümesinde saydığınız sayılar gerçek sıklığı değil, temsilcilerin alışkanlıklarını ölçer.
Etiket şemasını beş altı başlıkla başlat, ihtiyaç net biçimde ortaya çıktıkça büyüt. Otuz etiketli bir şema, kimsenin doğru doldurmadığı şemadır. Ayrıntıyı etikete değil, yanına açılan serbest metin alanına yazdır: hangi ekranda oldu, kullanıcı ne yapmaya çalışıyordu, nasıl çözüldü. Etiket saymak içindir, metin okumak için.
Satış tarafında ne var
Satış temsilcisi, ürünü henüz kullanmayan insanlarla konuşan tek kişidir. Elindeki bilgi bu yüzden farklıdır: kullanıcının ne beklediğini, neyi rakipte gördüğünü, hangi cümleden sonra ilgisinin dağıldığını bilir.
Bu bilginin bilinen sorunu, ağırlığın büyük hesaplara kaymasıdır. Bir temsilci, cirosunun yarısını getiren müşterinin talebini yüz küçük kullanıcının aynı anda dile getirdiği bir şikayetten daha yüksek sesle aktarır. Ama daha az konuşulan bir nokta var: kazanılan satışın gerekçesi ile kaybedilen satışın gerekçesi aynı değerde değildir. Kaybedilen satış çok daha bilgilendiricidir, ve tam da kimsenin ayrıntılı yazmak istemediği kayıttır. Kaybedilen fırsatların büyük kısmı sistemde "fiyat" olarak işaretlenir, çünkü fiyat kimseyi suçlamayan bir gerekçedir. Kaybedilen işlerin kapanış notunu zorunlu ve serbest metin yapın; oradan çıkan cümleler, aylık satış raporundaki grafiklerin hepsinden fazlasını söyler.
Satıştan gelen bir bulguyu doğrudan yol haritasına yazmayın. Onu bir hipotez olarak alın, sonra o hipotezi mevcut kullanıcılara sorun. Temsilcinin sezgisi genelde doğru yeri işaret eder, sebebi ise sıklıkla yanlış tahmin eder.
Bilgi nereye birikecek
Departmanlar arası akış konuşulurken tartışma hızla araç seçimine kayar. Halbuki asıl karar araçtan önce gelir: bu bilgi nereye yazılacak ve kim okuyacak. Bu iki sorunun cevabı belli değilse yeni bir platform açmak sadece boş bir sekme ekler.
Zaten kullandığınız sistemde bir yer varsa oradan başlayın. CRM'deki kapanış notu, destek yazılımındaki etiket alanı, proje panosundaki tek bir sütun çoğu ekip için yeterlidir. Ayda bir kez birinin oturup bu kayıtları okuması ve üç maddelik bir özet çıkarması, en pahalı geri bildirim panelinden daha fazla iş görür. Süreci ayakta tutan araç değil, o okuma randevusudur.
Değişikliğin işe yarayıp yaramadığını ölçmek
UX çalışmalarının etkisi genelde site geneline ait metriklerle raporlanır: ziyaret süresi, dönüşüm oranı, memnuniyet puanı. Bu metrikler yavaş hareket eder ve içine onlarca başka etken karışır, dolayısıyla tek bir düzeltmenin sonucunu göstermezler.
Daha dar ve daha dürüst bir ölçüm var. Bir sorunu düzelttiyseniz, o soruna karşılık gelen etiketin haftalık talep sayısını düzeltmeden önceki dört hafta ile sonraki dört hafta arasında karşılaştırın. Toplam trafikteki dalgalanmayı temizlemek için sayıyı o haftanın aktif kullanıcı sayısına bölün. Düşüş varsa, düzeltme tuttu. Düşüş yoksa, çözdüğünüzü sandığınız şey kullanıcının yaşadığı şey değildi. Bu ölçüm sadece kayda geçen sorunlar için çalışır, ki bu da yazının başındaki kör noktayı yeniden hatırlatır.
Kaynaklar