UX Araştırmacısı Mülakatı: Sorular ve Hazırlık Kurgusu
UX araştırmacısı mülakatlarında yöntem listesi ezberlemek işe yaramıyor. Karşı taraf hangi yöntemi bildiğini değil, onu neden seçtiğini ve sonucunda üründe neyin değiştiğini soruyor. Hazırlığı soru başına değil vaka başına kurarsan, yirmi soruya dört hikâyeyle cevap verirsin.
Yirmi soru, dört vaka
Mülakat rehberlerinin çoğu soru listesi verip her sorunun altına örnek hazırlamanı söyler. Bu tavsiye kendi içinde tutarsız. Tipik bir görüşmede on beş ile yirmi arası davranışsal soru gelir; kimse yirmi ayrı projeyi detayıyla hatırda tutamaz, tutmaya çalışan da üçüncü soruda karışır.
Bunun yerine dört proje seç ve her birini beş başlıkla hafızana yerleştir: sorulan asıl soru, seçtiğin yöntem ve elemenin gerekçesi, sahada bozulan şey, çıkan bulgu, bulgunun ürüne yansıyıp yansımadığı. Aynı proje, sorunun geldiği yöne göre farklı yüzünü gösterir. Öncelik sorusunda kapsamı nasıl daralttığını, çatışma sorusunda geliştirme ekibiyle nerede ters düştüğünü, başarısızlık sorusunda katılımcıların yanlış profilden geldiğini fark ettiğin anı aynı vakadan çıkarırsın.
Dördüncü vakayı bilerek kötü giden bir projeden seç. Her şeyin planlandığı gibi yürüdüğü dört hikâye anlatan aday, hikâyeleri kurguladığı izlenimi bırakır.
Yöntem soruları adı değil kararı sorar
“Hangi araştırma yöntemlerini kullanıyorsun” sorusunun cevabı liste değil. Bilgi mimarisi sorununda kart sıralamayla ağaç testi arasında neden birini seçtiğini, ikisini birden yapacak zamanın yokken hangisini feda ettiğini anlat. Yöntem adları zaten CV'de yazıyor, görüşmede ölçülen şey ayırt etme.
Nitel testlerde beş kullanıcı kuralı neredeyse her mülakatta bir yerde belirir. Ezberi tekrarlamak yerine sınırını söyle: o kural tek bir görev akışı ve tek bir kullanıcı grubu için kurulmuştur. Yeni kullanıcıyla uzman kullanıcının aynı ekranda tamamen farklı yerlerde takıldığı bir üründe, beş kişi tek bir grubun sorunlarını bulur ve diğerini görmezsin. Bu ayrımı yapan aday, yöntemi uygulamış olanla okumuş olan arasındaki farkı tek cümlede gösterir.
Ölçüm sorusu geldiğinde veriyi nereden alacağını söyle
Bir tasarım kararının işe yarayıp yaramadığını nasıl ölçeceğin sorulduğunda, metrik adı vermekle yetinme. Metriği söylemeden önce o olayın üründe loglanıp loglanmadığını sor. Çoğu üründe hazır bir “akış tamamlama oranı” yoktur; adımların ayrı ayrı olay olarak tanımlanması gerekir ve bu, araştırma başlamadan önce yapılacak birkaç günlük geliştirme işidir. Ölçümü tahtada değil üründe düşündüğünü gösteren şey bu cümledir.
Aynı dikkat A/B testi için de geçerli. Günlük trafiği düşük bir akışta anlamlı fark görmek haftalar alır, o süre boyunca sürüm de dondurulur. Bunu mülakatta baştan söylersen, yöntem seçiminin takvimle ilişkisini kurmuş olursun.
Paydaş ve çatışma soruları
Bu sorularda “açık iletişim kurarım” tarzı cevaplar hiçbir şey anlatmaz. Somut olan şudur: bulguyu kimin hangi kararına bağladın. Ürün yöneticisine kullanıcıların zorlandığını söylemek zayıf; aynı ekranda destek taleplerinin nereye yığıldığını gösterip önerilen değişikliğin bir sprintlik iş olduğunu söylemek karar üretir.
Araştırmanın reddedildiği durumu da hazırla. Bulgunun uygulanmama sebebi çoğu zaman bulgunun zayıflığı değil, zamanlamasıdır. Karar verilmiş bir işe iki hafta sonra gelen araştırma, doğru olsa bile rafa kalkar.
Sıra sende: ne soracaksın
Görüşmenin sonundaki soru hakkı, ekibin araştırmayı gerçekten kullanıp kullanmadığını anlamanın en ucuz yolu. Şunları sor: son üç araştırmadan hangisi ürüne yansıdı, katılımcı bulma işi kimin üzerinde, tekrar eden bulgular nerede birikiyor, bir araştırmacı kaç ekibe bakıyor.
Cevaplar karşı tarafı da açığa çıkarır. Katılımcı bulma işinin araştırmacıya bırakıldığı ve bulguların kişisel dosyalarda durduğu bir yerde, işin büyük kısmı araştırma değil koordinasyon olur. Bunu mülakatta öğrenmek, altı ay sonra öğrenmekten iyidir.