Yeni Bir Dijital Ürün İçin Kullanıcı Araştırması Nasıl Yapılır?
İçindekiler
- Varsayımları araştırma sorusuna çevirin
- Doğru katılımcıyı seçin
- Görüşmede fikri satmaya çalışmayın
- Söylenen ile yapılanı ayırın
- Ne zaman prototip kullanmalı?
- Kullanılabilirlik testinde görev verin, yönlendirmeyin
- Notları gözlem ve yorum olarak ayırın
- Kopyalanabilir araştırma planı
- Araştırma bitince ne yapılmalı?
Yeni dijital ürün için kullanıcı araştırmasının amacı insanlara fikrinizi beğenip beğenmediklerini sormak değildir. Kullanıcının bugün hangi işi yapmaya çalıştığını, bunu nasıl çözdüğünü, nerede zorlandığını ve önerdiğiniz çözümün hangi varsayımlarının test edilmesi gerektiğini anlamaktır.
GOV.UK Service Manual, araştırmaya ekip varsayımlarını araştırma sorularına dönüştürerek başlamayı ve yöntemleri bu sorulara göre seçmeyi önerir. GOV.UK: Plan user research
Varsayımları araştırma sorusuna çevirin
Zayıf varsayım:
Küçük işletmeler stok uygulaması ister.
Araştırma sorusu:
Küçük işletmeler bugün stoklarını nasıl takip ediyor ve hangi durumda mevcut yöntemleri yetersiz kalıyor?
İkinci ifade kullanıcıya sonucu söylemez ve mevcut davranışı anlamaya odaklanır.
Başlangıçta şu başlıklarda varsayımlar çıkarılabilir:
- Kullanıcı kim?
- Problem ne?
- Problem ne sıklıkta yaşanıyor?
- Bugün nasıl çözülüyor?
- Mevcut çözümün maliyeti veya zorluğu ne?
- Yeni çözümü kullanmak için davranış değişikliği gerekiyor mu?
Doğru katılımcıyı seçin
Ürünün hedef kullanıcısı muhasebeciyse yalnızca arkadaşlarınızla konuşmak doğru veri üretmeyebilir.
Katılımcı kriterleri ürünün gerçek kullanımına göre belirlenmelidir.
Örneğin:
Araştırma grubu:
- Son 6 ay içinde en az 20 aktif müşteriyi manuel takip etmiş
- CRM kullanmıyor veya temel bir CRM kullanıyor
- Müşteri takibini kendi işi içinde düzenli yapan
Bu kriter örnektir. Gerçek ürün için hedef kullanıcıya göre değiştirilmelidir.
GOV.UK, kullanıcı araştırmasında mevcut veya muhtemel kullanıcılarla çalışmayı ve farklı kullanıcı ihtiyaçlarını kapsayacak katılımcılar seçmeyi önerir. GOV.UK: User research introduction
Görüşmede fikri satmaya çalışmayın
"Bu uygulama olsa kullanır mıydınız?" sorusu genellikle zayıf veri üretir.
Bunun yerine geçmiş davranışa odaklanın:
- Son kez bu problemi ne zaman yaşadınız?
- Ne yaptınız?
- Hangi araçları kullandınız?
- En uzun süren adım hangisiydi?
- Hata olduğunda ne yaptınız?
- Bunun için para ödüyor musunuz?
- Bugünkü çözümü neden değiştirmediniz?
Derinlemesine görüşmeler, kullanıcıların koşullarını ve ihtiyaçlarını anlamak için kullanılabilir. GOV.UK rehberi de görüşmeleri kullanıcıların yaşamını, işini, mevcut deneyimlerini ve sorunlarını derinleştirmek için önerir. GOV.UK: In-depth interviews
Söylenen ile yapılanı ayırın
Kullanıcı bir özelliği "çok iyi fikir" olarak değerlendirebilir ancak gerçek hayatta bu probleme zaman veya para ayırmıyor olabilir.
Bu nedenle araştırmada:
- Geçmiş davranış
- Mevcut araç
- Harcanan zaman
- Mevcut ödeme
- Oluşan hata
- İş akışı
gibi somut kanıtları toplamaya çalışın.
Bu, kullanıcı görüşünü değersiz yapmaz. Sadece niyet ile davranışı ayrı veri olarak kaydetmenizi sağlar.
Ne zaman prototip kullanmalı?
Problem keşfi sırasında hiç tasarım göstermemek daha yararlı olabilir. Çünkü erken prototip kullanıcıyı sizin çözümünüze yönlendirebilir.
Çözüm varsayımlarını test etmeye geçtiğinizde ise:
- Kağıt taslak
- Figma prototipi
- Tıklanabilir akış
- Kod prototipi
kullanılabilir.
GOV.UK prototip rehberi, tasarım fikirlerini üretim koduna geçmeden önce keşfetmek ve kullanıcıyla test etmek için farklı doğruluk seviyelerinde prototipler kullanılabileceğini açıklar. GOV.UK: Making prototypes
Kullanılabilirlik testinde görev verin, yönlendirmeyin
Şöyle demek yerine:
Sol üstteki filtre butonuna basıp tarihi seçin.
şöyle bir görev verin:
Geçen ay oluşturduğunuz siparişleri bulmak istediğinizi düşünün. Nasıl yapardınız?
Moderasyonlu kullanılabilirlik testinde kullanıcıların belirli görevleri tamamlamasını gözlemlemek, anlamadıkları alanları ve kullanılabilirlik sorunlarını tespit etmeye yardımcı olur. GOV.UK: Moderated usability testing
Notları gözlem ve yorum olarak ayırın
Örnek:
Gözlem
Katılımcı "yeni kayıt" butonunu yaklaşık 20 saniye aradı ve önce Ayarlar menüsüne girdi.
Yorum
Ana işlem yeterince görünür olmayabilir.
İlk cümle gözlemdir. İkinci cümle ekip yorumudur. Bunları ayırmak analiz sırasında varsayımı gerçek davranış gibi yazmayı önler.
Kopyalanabilir araştırma planı
ARAŞTIRMA AMACI
Bu tur sonunda hangi kararı vermek istiyoruz?
ARAŞTIRMA SORULARI
1.
2.
3.
TEST EDİLEN VARSAYIMLAR
1.
2.
KATILIMCI KRİTERİ
Kimler:
Kimler değil:
YÖNTEM
[ ] Derinlemesine görüşme
[ ] Gözlem
[ ] Prototip testi
[ ] Moderasyonlu kullanılabilirlik testi
[ ] Anket
[ ] Diğer
OTURUM AKIŞI
Giriş:
Mevcut davranış:
Problem:
Mevcut çözüm:
Varsa prototip görevi:
Kapanış:
TOPLANACAK KANIT
Davranış:
Kullanılan araç:
Sıklık:
Maliyet / zaman:
Hata:
Alıntı:
Gözlem:
KARAR
Hangi bulgu ürünü değiştirmemize neden olur?
Hangi konu için yeni araştırma gerekir?
Araştırma bitince ne yapılmalı?
Görüşme notlarını tek tek "kullanıcı bunu istedi" listesine çevirmeyin.
Bulguları:
- Tekrarlanan problem
- Farklı kullanıcı grubu
- Mevcut davranış
- İhtiyaç
- Risk
- Ürün varsayımı
başlıklarında gruplayın.
Araştırma, tüm kullanıcıların aynı şeyi düşündüğünü kanıtlamak için yapılmaz. Bir ürün kararını daha az varsayımla verebilmek için yapılır.
İlk araştırma turunun sonunda yeni sorular çıkması normaldir. Kullanıcı araştırmasını yalnızca proje başında yapılan tek seferlik bir onay süreci yerine ürün geliştirme boyunca tekrarlanan öğrenme faaliyeti olarak ele almak daha sağlıklıdır.
Benzer bir konuda yardım mı lazım?
Projenizi anlatın, nereden başlayacağımızı birlikte bulalım.
