Bir UX Projesinin Başarısız Olacağını Gösteren Dört Sinyal
Bir UX projesinin başarısız olacağı, para bittiğinde değil çok daha önce belli olur. Sinyaller de gizli değildir: kimin için yaptığınızı söyleyemiyorsanız, test edecek kullanıcı bulamıyorsanız, geri bildirimler ikiye bölünüyorsa ya da kullanıcı ürünü kendi cümleleriyle anlatamıyorsa. Dördü de erken aşamada görünür, dördüne de müdahale edilebilir.
Kimin için yaptığınızı bir cümlede söyleyemiyorsanız
Projelerin çoğu çözümle başlar, kullanıcıyla değil. Fikir toplantıda iyi durur, ekip heyecanlanır, kod yazılmaya başlanır. Sonra ilk demoda "bunu kim kullanacak" sorusu gelir ve odada üç farklı cevap çıkar.
Bunu sınamanın ucuz bir yolu var: hedef kullanıcıyı tek cümlede tarif edin, cümlede sıfat değil davranış olsun. "Genç profesyoneller" bir tarif değildir. "Haftada en az üç kez ekipten dosya devralan muhasebeci" tariftir, çünkü doğrulanabilir ve yanlışlanabilir.
Pazar büyüklüğü tahminini de aynı cümleden türetin. Tarif daraldıkça sayı küçülür, bu kötü haber değil; küçük ama gerçek bir sayıyla çalışmak, büyük ve dayanaksız bir sayıyla çalışmaktan kolaydır.
Test edecek kullanıcı bulamıyorsanız
Araştırma aşamasında beş kullanıcı bulmakta zorlanıyorsanız, satış aşamasında beş yüz tane bulmanız beklenmesin. Dört sinyal içinde en erken görüneni budur, en çok göz ardı edileni de.
Ölçmesi zor değil. İlgili sayfanın trafiğine bakın, formu kaç kişinin doldurduğunu sayın, teste davet ettiklerinizin kaçının geldiğini not edin. Davet edilen otuz kişiden ikisinin gelmesi bir takvim sorunu değil, ilgi sorunudur.
Niş projelerde tablo başkadır. Kullanıcı sayısı azdır ama nerede toplandıkları bellidir, yani ulaşmak kolaydır. Ulaşılamayan bir niş, niş değildir.
Geri bildirim ikiye bölündüğünde
Aynı özelliğe bir grup bayılıyor, bir grup kızıyorsa ilk yorum genelde "segmentasyon sorunu var" olur. Çoğu zaman da doğrudur. Ama önce daha sıkıcı bir ihtimali elemek gerekir.
Beş kişilik bir testte üçe iki bölünme, tercihlerin tamamen rastgele dağıldığı durumda zaten en olası sonuçtur. Bölünmenin kendisi tek başına bilgi taşımaz. Bilgi taşıyan şey, bölünmenin ekseninin adını koyabilmenizdir: bir tarafta günde yirmi kayıt giren kullanıcılar, diğer tarafta ayda iki kez giren kullanıcılar. Ekseni söyleyemiyorsanız elinizde segment değil gürültü vardır ve yapılacak iş, örneklemi büyütmek ya da katılımcıları kullanım sıklığına göre ayırıp testi tekrarlamaktır.
Eksen belli olduğunda seçenekler netleşir. Ya kapsamı daraltıp tek segmente odaklanırsınız, ya da iki ayrı akış kurarsınız. İkinci segmentin getirisi maliyetini karşılamıyorsa onu bilinçli şekilde dışarıda bırakmak da bir karardır; ertelemek değildir.
Kullanıcı ürünü size anlatamıyorsa
Prototip testinde "beğendiniz mi" sorusu neredeyse her zaman evet getirir. İnsanlar karşısındakini kırmak istemez. Ekranı kapatıp şunu sorun: bunu bir arkadaşınıza nasıl anlatırdınız?
Kullanıcının ürünü kendi cümleleriyle anlatabilmesini, memnuniyet puanından daha güvenilir bir gösterge bulurum. Puan nazik olabilir, cümle olamaz. "Şey işte, bir panel, raporlar falan var" diyen kullanıcı değer önerisini almamıştır. "Ay sonunda üç ayrı yerden topladığım tabloyu tek ekranda görüyorum" diyen almıştır.
Aynı cümleyi ekibe de sordurun. Geliştiricinin ve satışçının verdiği cevaplar birbirini tutmuyorsa, kullanıcının tutmasını beklemek fazla iyimserlik olur.
Dördü aynı anda çıkarsa
Sinyaller tek tek düzeltilebilir. Hedef kitle yeniden tanımlanır, teste katılım için bütçe ayrılır, segment daraltılır, değer önerisi yeniden yazılır. Ama dördü birlikte görünüyorsa sorun genellikle uygulamada değil varsayımdadır: ortada çözülmesini isteyen kimsenin olmadığı bir problem vardır.
Bu noktada en ucuz hamle projeyi kurtarmaya çalışmak değil, problemi yeniden aramaktır. Yazılan kodun bir kısmı yeni yönde de işe yarar; aylardır savunulan varsayım yaramaz.
Kaynaklar