Kullanıcı Deneyimini İyileştirmenin Beş Somut Yolu
Kullanıcı deneyimi tartışması çoğu şirkette arayüzde başlar, arayüzde biter. Oysa bir kullanıcının sayfayı terk etme sebebi genelde buton rengi değil, aradığını bulamaması ya da bir adımda ne yapacağını anlamamasıdır. Aşağıdaki beş başlık, UX bütçesini nereye koyacağına karar veremeyen ekipler için sıralı bir yol.
UX arayüz işi değil
Bir ekranın nasıl göründüğü, deneyimin görünen yüzü. Altında bilgi mimarisi, arama, metin, hata mesajları, sayfa açılma süresi ve sistemin kullanıcıya nerede olduğunu söyleme biçimi var. Menüde üç tıkla ulaşılan sayfa, tasarımı ne kadar temiz olursa olsun bulunamıyorsa yok sayılır. Sitede derinlere inen bir yapı varsa kullanıcının konumunu gösteren bir gezinti izi koy; bu, tasarım değil bilgi mimarisi kararıdır ve genelde tasarımcıdan önce içerik tarafında verilir.
Ekibi tasarımcılardan ibaret tutma
UX ekibin sadece tasarımcılardan oluşuyorsa, sorunların yarısını göremeyecek bir masa kurmuşsun demektir. Analitiği okuyan kişi hangi adımda kayıp yaşandığını, geliştirici hangi akışın teknik olarak neden yavaş olduğunu, destek ekibi kullanıcıların hangi cümleyi yanlış anladığını bilir.
Pratik hâli şu: iki haftada bir yarım saatlik bir toplantı yap, gündem sadece "bu dönem kullanıcılar nerede takıldı" olsun. Destek biletlerinden gelen tekrar eden üç şikâyet, çoğu kullanıcı testinden daha hızlı yol gösterir.
Araştırmaya ayrı bütçe aç, ama hangisine
Bu konuda sık verilen iki tavsiye birbiriyle çelişir: "araştırma çok az bütçeyle yapılabilir" ve "ciddi araştırma için ayrı bütçe şart". İkisi de doğru, ayrım şurada.
Mevcut bir arayüzün kullanılabilirlik sorunlarını bulmak ucuzdur. Birkaç kişiyi karşına al, görevi ver, sus ve izle. Tökezlemelerin çoğu ilk oturumlarda ortaya çıkar. Buna bütçe ayırmak yerine takvime yer açman yeterli.
Pahalı olan kısım başka: yeni bir kitleye, yeni bir pazara ya da farklı bir kültüre açılırken hangi ürünün işe yarayacağını anlamak. Orada koridor testi seni yanıltır, çünkü test ettiğin insanlar zaten senin dünyandan. Bu tür kararlarda saha araştırmasına gerçekten para ayır. Küçük bir pilotla başla, işe yarayan yöntemi büyüt.
Kararı veriye bağla, testin sınırını bilerek
Kişisel kanaat yerine kullanıcı testi, analitik ve doğrudan geri bildirim. Buraya kadar herkes hemfikir. Atlanan kısım, A/B testinin çalışması için trafiğin yetmesi gerektiği.
Kaba bir hesap: dönüşüm oranın %3 ise ve bunu %3,3'e çıkaran bir değişikliği güvenilir biçimde görmek istiyorsan, varyant başına elli bin civarı ziyaretçiye ihtiyacın var. Ayda beş bin ziyaretçi alan bir sitede bu test bir yıl sürer, o süre içinde ürün de trafik kaynağı da değişir. Böyle bir sitede A/B testinin sonucuna bakıp karar vermem; onun yerine beş kişiyle yapılan bir oturumun kaydını izlerim, çünkü orada sinyal cümlelerin kendisinde, sayıda değil.
Testin anlamlı olduğu yer yüksek trafikli akışlardır: ödeme adımı, kayıt formu, ana sayfa. Düşük trafikli sayfalarda nitel yöntemlere geç.
Ne ölçtüğünü baştan seç
Değişiklik yayına çıkmadan önce hangi sayının değişmesini beklediğini yaz. Sepeti terk etme oranı mı, ilk oturumda görevi tamamlayan kullanıcı yüzdesi mi, destek biletlerinin sayısı mı. Sonradan bakılan metrik, her zaman iyi görünen metriktir.
Genel memnuniyet anketleri karar vermek için zayıf kalır, çünkü kullanıcı beğenmediği şeyi çoğu zaman adlandıramaz. Bunun yerine tek bir görevi tanımla ve tamamlanma oranıyla süresini takip et. Bir de her sürümde toplanan serbest metin geri bildirimlerini kategorilere ayır; tekrar eden üç başlık, öncelik listenin kendisidir.
Kaynaklar