UX Araştırma Portföyü: Şablonu Değil Kararları Gösterin
UX araştırma portföyü, yapılmış testlerin listesi değildir; bir karar geçmişidir. Bakan kişi hangi yöntemi neden seçtiğinizi ve çıkan bulgunun ürünü nereye ittiğini görmek ister. Çoğu portföy tam burada tökezliyor: süreci anlatıyor, seçimleri savunmuyor.
Portföy aslında neyi kanıtlıyor
Görsel düzen ilk on saniyeyi kurtarır, gerisini içerik taşır. Kullanıcı araştırması davranışın kök sebebini bulmakla ilgiliyse, portföyün göstermesi gereken de budur: elinizde ham bir gözlem yığını varken hangisini önemli saydınız, hangisini elediniz, neye dayanarak?
Peki proje başarısız olduysa ne olacak? Yanlış bir hipotezle başlayıp testte çürüten bir vaka, "tamamlanma oranı arttı" diye biten bir vakadan çoğu zaman daha ikna edici. Araştırmanın işlevi zaten o: fikri ucuz aşamada öldürmek. Bunu portföye koymaktan çekinmeyin, ama neden yanıldığınızı ve sonra ne değiştirdiğinizi de yazın.
Beşli şablon işe yarar, üç kez tekrarlanınca yaramaz
Problem, rol, yöntem, bulgu, sonuç. Bu sıralama okuyucuya nerede olduğunu söyler ve atlaya atlaya okumayı kolaylaştırır. Sorun şablonun kendisinde değil, üç vakanın da aynı kalıpla ve aynı uzunlukta yazılmasında.
Geçen sene işe alım için bakılan bir portföyde üç vakayı arka arkaya okudum; üçüncünün sonuna geldiğimde ilkinin ne hakkında olduğunu hatırlamıyordum. Hepsi düzgündü, hiçbiri ayırt edilmiyordu. "Klişe portföyden kaçının" diyen rehberlerin verdiği hazır iskelet, bire bir uygulanınca klişenin kendisini üretiyor.
Pratik karşılığı şu: bir vakayı derinlemesine anlatın, kalanları birer paragrafa indirin. İkinci vakaya yöntem tartışmasından, üçüncüsüne kullanıcı alıntısından girin. Aynı bilgiyi taşıyan farklı girişler, okuyucunun dikkatini ayakta tutar.
Yöntem çeşitliliği iddia değil, gerekçe ister
Portföyde farklı yöntemlerin bulunması iyidir, ama liste halinde saymak bir şey kanıtlamaz. Kanıt, seçimin gerekçesindedir.
- Keşif: Derinlemesine görüşme ya da saha gözlemi. Problem henüz tanımlı değilken anlamlı; tanımlıysa zaman kaybı.
- Değerlendirme: Kullanılabilirlik testi, A/B. Elinizde test edilecek somut bir akış varken çalışır.
- Nicel ve nitel birlikte: Analitik nerede düştüğünü söyler, görüşme neden düştüğünü. Biri olmadan diğeri yarım kalır.
Beş kullanıcıyla yapılan bir testin sonucunu yüzdeyle sunmak, portföyde en sık gördüğüm hata. Beş kişinin dördü demek yüzde seksen demek değildir; küçük örneklemde yüzde yazmak sayıya taşıyamayacağı bir kesinlik yükler.
Sonuç metriğini savunabiliyor musunuz
"Onboarding tamamlanma oranı yüzde otuz arttı" cümlesi tek başına havada durur. Aynı dönemde yeni sürüm mü çıktı, kampanya mı vardı, trafik kaynağı mı değişti? Karşılaştırma grubu ya da en azından aynı anda giden diğer değişikliklerin listesi olmadan artışı araştırmaya bağlayamazsınız.
Sayıyı vermeyin demiyorum. Bağlamıyla verin: ölçüm penceresi, örneklem, aynı dönemdeki diğer müdahaleler. İşe alım tarafında oturmuş biri için bu ayrıntılar sayının kendisinden daha bilgilendirici, çünkü nedenselliği nasıl kurduğunuzu gösterir.
Çoğu araştırmacının sonucu hiç göremediği de bir gerçek: ölçüm ürün ekibinde kalır, siz projeden çıkarsınız. O durumda uydurulmuş bir yüzde yazmak yerine hangi kararın değiştiğini yazın. "Kayıt akışındaki iki adım birleştirildi" da ölçülebilir bir çıktıdır.
Hikaye, ekip ve kapanış
Kullanıcı alıntıları bulguyu insani kılar, persona ve yolculuk haritası okuyucuya bağlamı hızlı verir. Bunları süs olarak değil, iddianızın kanıtı olarak yerleştirin: hangi alıntı hangi tasarım kararını tetikledi?
Ekip çalışması kısmında "paydaşlarla iletişim kurdum" gibi cümleler boş geçiyor. Bunun yerine anlaşmazlığı anlatın. İş hedefiyle kullanıcı ihtiyacının çakıştığı bir an, çözümüyle birlikte, on maddelik yetkinlik listesinden daha çok şey söyler.
Kapanışta "benimle iletişime geçin" cümlesine gerek yok. İletişim bilgisi görünür olsun, yeter; portföyü buraya kadar okuyan kişi zaten ne yapacağını biliyor.
Kaynaklar